[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


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.