[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[xmlblaster] xmlrpc v3 plugin; callback timing?
- To: xmlblaster at server.xmlBlaster.org
- Subject: [xmlblaster] xmlrpc v3 plugin; callback timing?
- From: "Póka Balázs" <p.balazs at gmail.com>
- Date: Tue, 4 Sep 2007 14:01:29 +0200
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=FbDc0S329kGm6YKpjSW045+sh6Ttu99e7BvXl1VT3S/bI2ditOK5kP87TH7Pf95njOuRd3a65etzRbkcTSswL7Y5ikodolxCpOjWDiSjrXJ/LAqu8YXHG0bSrJqYP6rjTMzV6+dOR6uNwGEdU1itWaIYxydmT2zmyw7MVyng6kg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=huOhoJ2y8t5DV46jwSBaaKcR7+J5FZ+W3abuW8tr43d3qDfKGSar46+laCE7FWGJTvriDw0tDRYU+OkmvQoP96SZYfDbrxQtQzxGqENKGVrGtWYFOrioN+Mohe/kh1MvVOh5Dh3UMHiaFrka5Kwi0LiRBFNv8b+ca3E0lvxZIb4=
- Reply-to: xmlblaster at server.xmlBlaster.org
- Sender: owner-xmlblaster at server.xmlBlaster.org
A few weeks ago, I went on to implement an XMLRPC plugin with some badly needed features:
- using Apache XMLRPC library v3 (compression, streaming, whatever)
- XMLRPC v3 can be configured to use Apache HTTPClient, which supports proxies and various authentication protocols
- updates are received using client polling (so that it works from behind proxies, NAT and so on)
...and I think it's ready to be shown to other people, too. It has been running for some weeks now in our testing environment and for a few days in production. Bugs are found here and there, of course.
I'd be glad to donate the code to the xmlBlaster project. It only needs package name refactoring, since I didn't use org.xmlBlaster as the prefix.
In a quite recent attempt to fix something, I have noticed some potentially buggy behaviour while debugging an update related problem.
I configured the callback address like this:
CallbackAddress cba=new CallbackAddress(glob, "XMLRPC3");
and expected to see a retransmit event every 20 seconds. Retransmitting works by waiting in update() for a poll made by the client for a 'timeout' number of milliseconds. If no polling call is made during that time (or no poll was received for at least 'timeout' milliseconds), it throws a communication exception which makes the connection to go into polling state.
The code at org.xmlBlaster.util.dispatch.DispatchConnection:596
spanPingTimer(400, false); // do one instant try
seems to override the expected behaviour which is set up at line 586:
timerKey = this.glob.getPingTimer().addTimeoutListener(this, this.address.getDelay(), "poll");
According to the log, the retransmit event really occur at 400ms intervals, and not 20000ms as expected.
So, am I interpreting the expected behaviour erroneously or is it really a bug? :)