I have put a JIRA in AXIOM reporting this issue: https://issues.apache.org/jira/browse/WSCOMMONS-201
Chathura 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] > >
