[JAVA] xml-rpc niet te catchen error bij sluiten client

[Drak0z]

Beste medetweakerts,

Op mijn stage ben ik bezig met een client-server systeem voor de aansturing van LED verlichting. Op zich gaat alles prima, maar lopen we sinds kort tegen een probleem aan.
Serverside gebruiken wij Sheevaplugs met openjdk en cacao ter optimalisatie. Zonder cacao draait alles echt extreem sloom (updates over de usb->dmx converter verlopen dan ongeveer 1x per seconde). Met cacao draait alles vrij goed (refreshrate van circa 20x per seconde).
Het probleem zit hem in het een-richtingsverkeer van XmlRpc icm het opvragen van updates.
Wanneer een client om updates vraagt komt de server in een functie die óf alle bekende updates voor die betreffende client terug geeft óf wacht tot er updates zijn (tot een bepaalde timeout optreedt uiteraard, dan geeft de functie gewoon een lege vector terug). Reden dat we serverside wachten is dat je op die manier zodra er wel iets verandert je netjes iets terug geeft, maar je dus niet elke 100ms een request vanaf de client krijgt.
Wanneer de client om de een of andere reden op z'n bek gaat, geeft de server een (logisch te verklaren) XmlRpc error, namelijk dat de client connectie gereset is. Onder Eclipse (met sun java dus) krijg ik deze error en wordt die gecatcht door de Apache XmlRpc server (en geschreven naar een log). De server blijft daarna netjes doordraaien.
Wanneer ik de server op een Sheevaplug met openjdk zet, zonder cacao, gaat dit ook goed (afgezien van de snelheid dan).
Wanneer ik de server op een Sheevaplug opstart met -cacao, krijg ik de error, maar wordt hij om de een of andere reden niet goed afgevangen en gaat de server dus hard op z'n bek.
Het ligt dus op de een of andere manier aan openjdk icm cacao JIT dat de server crasht in plaats van de error netjes catcht. Mijn vraag is eigenlijk of iemand dit probleem al eerder tegengekomen is en of het op te lossen is zonder de timeout/wacht functie in de updates er uit te halen en door gebruik te blijven maken van openjdk (omdat sun z'n arm applicatie slechts 90 dagen te gebruiken is).

Lastig om zo'n probleem te omschrijven in gewone tekst, maar ik hoop dat 't een beetje duidelijk is

[Killemov]

Als je zelf de connecties beheert kun je in ieder geval een Throwable (specifieker == beter) catchen om je connectie of connectie manager heen. Als jouw code slechts onderdeel is van een framework dat de connecties voor jou beheert dan zit daar dan ook het probleem ... een bug lijkt me. Verder ben ik nog niet overtuigd van het practische nut van xml-rpc. Ik werk liever met een eigen protocolletje, dat is iets meer werk maar dan heb ik wel de volledige controle over de communicatie.

Leuk trouwens zo'n Sheevaplug, ik heb zelf een QNAP TS119, dat is toch hetzelfde platform? (arm/kirkwood)

[Drak0z]

@Killemov We hebben er specifiek voor gekozen om XmlRpc te gebruiken zodat het ook makkelijk is voor andere clients om naar 'onze' server te connecten. Zo is er al een domotica applicatie hier ontwikkeld en hebben ze ook een php applicatie die met die domotica connect. Beide apps kunnen met minimale inspanning nu connecten met onze server. Mee eens dat het fijner is om je eigen protocol te schrijven en indien mogelijk gewoon lekker sockets te gebruiken, maar helaas :-)
Daarbij, het zal een bug zijn van de Apache XmlRpc Webserver implementatie (waar ik overigens geen fan van ben, maar ik ben dik 3 dagen bezig geweest met het proberen op te zetten van, en gebruik maken van, XmlRpc over Apache Servlets, terwijl ik binnen 5 minuten de Webserver implementatie had draaien) icm Cacao. Omdat het in de Apache implementatie al gecatcht wordt (en gelogd) kan ik het dus nergens anders meer afvangen. Het vervelende is alleen dat onder Cacao hij niet gecatcht wordt.

Wij maken gebruik van zowel Sheevaplugs (2), Guruplug Servers (1) en Guruplug Server Plussen (2). Vooral die laatste zijn heerlijk om mee te werken (tot je ze op een gbit aansluit, dan reboot ie met kernel panic >_< ), maar in de basis zijn het inderdaad allemaal ARM/Kirkwood dingen.