[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] xmlrpc v3 plugin; callback timing?
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:
> 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.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? :)
> Balázs Póka
> lead developer
> iData kft.