Paul
I agree in theory that we should use a good UUID generator.. and the
"right" thing to do here is fix it where the problem is - in Axiom.
However, due to the time lines, I have fixed the existing UUID generator
to be thread safe without having to use synchronization. This fix runs
fast and correctly. So lets get the correct fix into Axiom, and remove
our implementation - which has been meant as 'throwaway'
asankha
Paul Fremantle wrote:
What about commons id:
http://jakarta.apache.org/commons/sandbox/id/uuid.html
On 5/5/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
I'm concerned about the performance implication of having a threadsafe
UUID generator. Are there any algorithms for generating UUIDs very
fast?
Paul
PS nice work figuring this out!!! It can't have been easy.
On 5/5/07, Chathura Ekanayake <[EMAIL PROTECTED]> wrote:
> Hi Paul, Asankha,
>
> This error is not caused by the timeout handler. If a timeout is
not set,
> its default
> action is to do nothing. That means, it will never timeout and
callbacks
> will not be removed by it.
>
> This error is caused by a bug in the UUIDGenerator of AXIOM.
UUIDGenerator
> generates
> same UUID multiple times, when it is invoked large number of times
> concurrently.
> Therefore, some of the outgoing messages (Synapse to server) get
the same
> UUID as the message ID.
> Once the response to first such message arrives at Synapse, its
callback is
> removed and subsequent
> messages with the same ID won't find a callback. Therefore they
produce the
> below error:
>
> [HttpClientWorker-3] WARN SynapseCallbackReceiver - Synapse received
> a response for the request with message Id :
> urn:uuid:7CD39BD337DE2BBBCD1178099875927 But a callback has
> not been
> registered to process this response.
>
> Synchronizing the UUIDGenerator access code in Synapse (inside
> Axis2FlexibleMEPClient.cloneForSend())
> solves the problem. But I think a better approach would be either
to make
> the AXIOM's UUIDGenerator thread safe
> or have our own thread safe UUIDGenerator in Synapse.
>
> Chathura
>
>
> On 5/3/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
> > Chathura
> >
> > I suspect that these were 'cleaned up' by the timeout handler..
Whats
> > the default timeout we have set to clear timeouts? Could you look
into
> > this issue and set a value that would not hurt performance
testing.. I
> > am assuming one minute to reply and then timeout is reasonable..
Maybe
> > we should log an INFO message with the message ID for timeouts
that we
> drop?
> >
> > asankha
> >
> > Paul Fremantle wrote:
> > > When I load up Synapse I'm seeing the following error:
> > >
> > > [HttpClientWorker-3] WARN SynapseCallbackReceiver - Synapse
received
> > > a response for the request with message Id :
> > > urn:uuid:7CD39BD337DE2BBBCD1178099875927 But a callback
> has not been
> > > registered to process this response.
> > >
> > > Under light load it doesn't happen but the more you load the
more of
> > > these messages I get. When this happens the response never
comes back
> > > to the test client. When I ran 1000 hits from 20 concurrent
clients,
> > > 38 of them got lost this way.
> > >
> > > Paul
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
