Java RMI MarshalException

Fejlesztés

Sziasztok!

Végső elkeseredésemben már ide is írok, háta van errefelé Java RMI fan. A problémám a következő:
Van egy osztott rendszerem - szerver algoritmusokat futtat, számol, több szálon; kliens feladatokat indít el és folyamatosan csekkolja az eredményt. Van ugye egy közös interfész és egy Result object. Mind2 jelen van mind2 oldalon.

Az egész architektúra nagyon szépen működött, soha egyetlen elszállás, vagy kivétel.
Egyik nap viszont a megrendelőm hív, hogy elszáll nála az alábbi kivétellel a cucc és hogy miért.
Nálam 100-ból 1-szer fordul elő, míg nála 100-ból 100-szor! ADSL kapcsolaton gyakrabban, nekem az egyetemni hálón soha nem száll el.
Hozzá kell tennem , hogy semmi, azaz SEMMI nem változott a kódon, egyik oldalon sem.

Kíváncsi volnék, hogy valaki találkozott -e már ezzel a problémával.
Köszönöm a válaszokat!

A kivétel:
java.rmi.MarshalException: error marshalling arguments; nested exception is:
javax.net.ssl.SSLException: Connection has been shutdown:
javax.net.ssl.SSLException: java.net.SocketException: Connection reset by
peer: socket write error

  • 1934 megtekintés

( uid_4656 v | 2007. 01. 23., k – 15:01 )

Lejárt az SSL-hez használt certificate? :-)

( drojid | 2007. 01. 23., k – 15:58 )

Ugyanazon a platformon futtatja, mint Te? Nem foghatja meg valami? Personal firewall, ilyesmi?

( razta | 2007. 01. 23., k – 17:42 )

Az exception alapján megszakad a kapcsolat (a kliens oldal bont). Én azt szoktam csinálni, hogy keepalive csomagokat küldök, hogy ne timeout-oljon a kapcsolat. Így a kapcsolat fennmarad akármeddig (akár hetekig is) windowson és linuxon egyaránt. Persze ha megszakad az internetkapcsolat valamelyik oldalon, akkor újra kell csatlakozni! Ehhez persze megfelelő módon kell megírnod a programot.

Amit a többiek írtak az is igaz. Ha a tűzfal blokkol valamit, akkor is gond lehet.

Egy harmadok dolog, hogy ha eltér a java verziószáma (minor szám), akkor is lehetnek furcsa dolgok. Gyakran fordul elő, hogy a szerver 1.4-es javat futtat, de a windows klienseken a java frissül 1.5-re automatikusan, és így gondok lesznek az RMI-s alkalmazásokkal.

Remélem ez segít valamit

köszi a válaszokat.

az exception-t én is értem, viszont a keepalive csomagot még nem próbáltam. guglizás közben nagyon sok helyen olvastam, hogy windows sokkal hamarabb timeoutol, így érthető, hogy linux alatt, nálam és másoknál miért nem jelentkezett a probléma. a tűzfal természetesen kizárva, arra figyelek, és ha blokkolna, akkor a fentebb említett login metódus sem hívódna meg.

java verzióra is figyelek (azé' nem vagyok amatőr :)), mivel a különböző verziók különböző bájtkódot generálnak, így szerializáció is más és mást csinálhat az objektumokból, ha a verzió különbözik.

szal a következő lépés a keepalive csomagok küldése. meg lehet ezt oldani magasabb szinten is, vagy kénytelen vagyok felüldefiniálni valami rmi-s osztályt?

csinálj vmi trace-t
vagy kapcsoltasd ki a firewallokat
rmi-ben az a szép, hogy nyitogatja a portokat... én akkor láttam ilyent amikor jól alánk konfigooták a firewall-t. Szerencsére a trace-ből lól ki lehetett olvasni a dolgot.

remélem segített
-TamsA-
..............................................................
Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

:) a firewallokat nem egyszerű innen kikapcsolni (egyetemi kapcsolat), de ha elolvasod az előző postokat, akkor láthatod, hogy ugyanazon környezet alatt eddig egyszer sem szállt el. a hiba egy bő hete jelentkezett először, de semmi nem változott ahhoz az állapothoz képest, amikor minden működött. a kliensoldalon random 1000 feletti, a szerver odlalon fix portot használ. milyen trace-re gondolsz? valami java.rmi.xxx property van erre?

Nem tudod sniffelni a forgalmát?
Tuti random porton beszélnek? Nem lehet, hogy mindig pont oda nyitna, ahol már figyel valami szolgáltatás?
Esetleg jogosultság probléma 1024 alatt?

Ugye majd megírod, ha megtalálod a gondot? :-D

("de semmi nem változott ahhoz az állapothoz képest, amikor minden működött." - de hát _valamit_ csak változtattak...)

nos, elvileg az implementáció van olyan okos, hogy azt a portot, amit használna, "leellenőriz", azaz látja, hogy socket arra még nincsen nyitva. de se perc alatt meg lehet csinálni, hogy fix ip legyen.

változni csak a hálózat változhatott, amire sajnos nincsen rálátásom: csak két rendszergazdát ismerek az egyetemen, de egyikőjük sem tud semmi topológiai változásról...

tegnap feltoltam a régi szerver-kliens párost is, már az is elszáll azokban a helyzetekben, ahol a legfrisebb, szal kizárt, hogy a kódban lenne hiba, legalábbis ha eddig gond nélkül működött.

A keepalive dolgot legegyszerűbb úgy megoldani, hogy pl. fél percenként meghívsz egy erre szolgáló metódust. Ez forgalmat generál. Nekem ez tökéletesen működik. Ennél alacsonyabb szintre nem kellett mennem. Ha jól emlékszem, akkor van egy property is, amivel be lehet állítani a default TCP timeout-ot.