[xmlblaster] xmlrpc v3 plugin; callback timing?

["Póka Balázs" <p.balazs at gmail.com>]

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.