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]
