You need to clean the thread local.
In the processExchange method, just do:

protected void processExchange(MessageExchange exchange) throws Exception {
  try {
     corrId.set(exchange.getProperty("correlationId"));
     ... put the current code here ...
  } finally {
     corrId.set(null);
  }
}

This way you should not experience the problem you explained.

On 11/22/06, Gianfranco Boccalon (JIRA) <[EMAIL PROTECTED]> wrote:
    [ 
https://issues.apache.org/activemq/browse/SM-751?page=comments#action_37515 ]

Gianfranco Boccalon commented on SM-751:
----------------------------------------

I implemented the solution you suggested, but I found some problems.
Let me explain how I implemented your suggestion:

- The method processExchange is invoked when a message is sent to a
component and the component should process it.
In this method I check for the correlation id in the message exchange,
and only if present, i set this correlation id in the threadlocal variable.

- The method sendConsumerExchange is invoked by a component to send
messages to other components.
In this method I check for the correlation id property in the message
exchange (may be that the component has already setted it).
If it'snt present, I look for the correlation id in the thread local
variable (that should be setted by the invocation of processExchange
method) and if present, i use it, otherwise i generate a new correlation
id that i set in the message exchange and in the threadlocal variable.

Now, I expose a simple ServiceAssembly where this change doesnt work.
The service assembly is:
HTTP BC->Splitter SE->Router SE->Screen BC

Executing the process the first time, all work properly: the invocation
of sendConsumerExchange by HTTP BC generate the correlation id, and this
id is propagated through all components (the lightweight component have
to be changed to propagate the id).
But executing the process a second time, the invocation of
sendConsumerExchange by HTTP BC finds a correlation id in the
threadlocal variable, because i suppose that there is a thread pool, and
we are using the same thread used in the first process activation.
The result is that the second invocation use the same correlation id
used by the first invocation.

I suppose there are 2 possible solutions (not alternative):
- Clean the threadlocal variables when the component finish its work:
the problem is where to do this clean-up. There is a place to do once
for all components ?
- The HTTP BC should generate the correlation id, so it has priority
over the thread local correlation id.
In this way all BC should be modified.

Any suggestion ?

Gianfranco Boccalon





> Flow tracing with correlation id
> --------------------------------
>
>                 Key: SM-751
>                 URL: https://issues.apache.org/activemq/browse/SM-751
>             Project: ServiceMix
>          Issue Type: Improvement
>            Reporter: Gianfranco Boccalon
>         Attachments: servicemix-components.zip
>
>
> Add the possibility to trace the flow of the messages inside a Service 
Assembly.
> For example, if we have a Service Assembly composed of three components, two 
binding components (call them BC1 and BC2) and a service engine (SE) organized in this 
sequence BC1->SE->BC2, we need to recognize that the output messages produced by 
the SE component are related to some messages provided by BC1.
> To do this, we need to add a "process correlation id" to the message 
exchanges and to modify the used components, to propagate this correlation id in all Message 
Exchanges sent.
> Enclosed there is the modified code for the following components:
> - HTTP binding component: here I added the code to generate the correlation 
Id and set it in the Message Exchange
> - Splitter
> - Router (the lightweight component)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Cheers,
Guillaume Nodet

Reply via email to