Hi!
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");
cba.setDelay(20000L);
cba.setRetries(-1);
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? :)
regards,
Balázs Póka
lead developer
iData kft.
