Re: [xmlblaster] xmlrpc v3 plugin; callback timing?

[Michele Laghi <michele at laghi.eu>]

Hi Póka,
you are right that the timer is overwritten , but this is a behaviour
which is desidered when the state first changes from alive to polling,
on the next sweep the delay will not be overwritten since the
reconnect=false.

The logs however are wrong, I will fix them.

For the XMLRPC Code of course we would be more than happy, as you
mentionned earlier the old XMLRPC Library is kind of outdated.

Michele


Póka Balázs wrote:
> 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.