You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Andrea Zoppello <zo...@libero.it> on 2006/12/19 14:20:55 UTC
Correlation Id in Pipeline component
Hi all,
this question is related to the change with id SM-751 on Jira.
I tried a simple process composed in this way: HTTP BC->PIPELINE (that
sends a message to another HTTP BC to invoke an external
WebService)->Screen BC.
The problem is related to the propagation of correlation id, generated
by the first HTTP BC.
The correlation id is propagated in the right way until the message sent
by PIPELINE to Screen BC: in this case a new correlation id is
generated, and this is not the right behaviour.
The problem is in the method processAsync that handle the first message
exchange for the pipeline: in this method the utility method
MessageUtil.transferOutToIn(exchange, me) is used to transfer some
properties from the source message to the destination message.
The problem is that also some properties from the source message
exchange (not only message) have to be copied in the destination message
exchange: in our case the property is the correlation id.
So I changed the class MessageUtil adding a method
copyExchangeProperties that I use in all transferXXToYY methods that
works with Message Exchanges.
In my implementation I copied only the correlation Id because i saw that
copying all properties give some problems.
With this patch all seems work properly.
Is this the right way to solve the problem ?
Should I raise a Jira about this ?
Thanks
Andrea Zoppello
Engineering Ing. Informatica
Re: Correlation Id in Pipeline component
Posted by Gianfranco Boccalon <gb...@tiscali.it>.
I think that the problem in my case is that the sending of the fourth
message exchange is not done by method
AsyncBaseLifeCycle#sendConsumerExchange, so the correlation id is not
propagated.
I'll evaluate the usage of ServiceMix 3.1.
Thanks
Gianfranco Boccalon
Guillaume Nodet ha scritto:
> I have just tested with the junit PipelineTest#testInOut test
> and it works fine: the correlationId is set when the exchange comes
> to the receiver target. As you are using a patched 3.0 version,
> I would suggest to check the code in AsyncBaseLifeCycle
> with the one in 3.1.
>
> Note that the behavior your see when at your breakpoint is correct,
> as the correlationId will be set when the send method is called.
> This method delegates to the BaseLifeCycle#sendConsumerExchange
> which will correctly set the correlationId.
>
> On 12/22/06, Gianfranco Boccalon <gb...@tiscali.it> wrote:
>> I debug the execution, so I can send you some details.
>>
>> The entire message flow is the following:
>> 1. HTTP BC->ENRICHER (PIPELINE)
>> 2. ENRICHER->HTTP BC FOR ENRICHER
>> 2.1 Invocation of external web service by HTTP BC FOR ENRICHER
>> 3. HTTP BC FOR ENRICHER->ENRICHER
>> 4. ENRICHER->SCREEN BC
>>
>> The problem arise in step 4: here a new correlation id is created
>> because the exchange sent doesnt contain the correlation id of the
>> previous exchanges.
>>
>> You can see the reason from this stack trace:
>> Thread [Thread-31] (Suspended (breakpoint at line 85 in MessageUtil))
>> MessageUtil.transferOutToIn(MessageExchange, MessageExchange) line:
>> 85
>> Pipeline.processAsync(MessageExchange) line: 288
>> Pipeline(EIPEndpoint).process(MessageExchange) line: 241
>> EIPLifeCycle(AsyncBaseLifeCycle).processExchange(MessageExchange)
>> line: 447
>> EIPLifeCycle(BaseLifeCycle).onMessageExchange(MessageExchange) line:
>> 43
>> DeliveryChannelImpl.processInBound(MessageExchangeImpl) line: 624
>> SedaFlow(AbstractFlow).doRouting(MessageExchangeImpl) line: 169
>> SedaFlow.doRouting(MessageExchangeImpl) line: 177
>> SedaQueue$1.run() line: 227
>> WorkerContext.run() line: 291
>> PooledExecutor$Worker.run() line: not available
>> Thread.run() line: 595
>>
>> The method transferOutToIn copy only message properties from source
>> message to destination message, it doesnt copy the message exchanges
>> properties from the source to destination.
>> I remind you that we are using ServiceMix 3.0.
>>
>> Here you can see a trace of messages until step 3 (included).
>>
>> ============================ Exchange
>> ==================================
>> MEP: org.apache.servicemix.jbi.messaging.InOnlyImpl
>> Id & status: ID:boccalon-1684-1166781393627-9:2 Active
>> Sender:
>> {http://servicemix.org/cheese}myGenericEnricherEnricher:myWebServiceEnricher
>>
>> Service: {http://servicemix.org/cheese}myGenericEnricherEnricher
>> Endpoint: null
>> Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
>> Interfacename: null
>> Operation: {http://soa.eng.it}arricchisciAnagrafica
>> ----- Properties
>> ----- Property [org.apache.servicemix.datestamp] -->
>> [java.util.GregorianCalendar[time=1166781979680,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=680,ZONE_OFFSET=3600000,DST_OFFSET=0]]
>>
>> ----- Property [org.apache.servicemix.correlationid] -->
>> [ID:boccalon-1684-1166781393627-9:2]
>> ----- Property [org.apache.servicemix.senderEndpoint] -->
>> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myWebServiceEnricher]
>>
>> ============================ Exchange
>> ==================================
>> MEP: org.apache.servicemix.jbi.messaging.InOutImpl
>> Id & status: ID:boccalon-1684-1166781393627-8:2 Active
>> Sender:
>> {http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
>>
>> Service: {http://servicemix.org/cheese}myGenericEnricherEnricherHttp
>> Endpoint: null
>> Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
>> Interfacename: null
>> Operation: null
>> ----- Properties
>> ----- Property
>> [Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
>>
>> --> [ID:boccalon-1684-1166781393627-9:2]
>> ----- Property [Pipeline.Transformer] --> [true]
>> ----- Property [org.apache.servicemix.datestamp] -->
>> [java.util.GregorianCalendar[time=1166781979730,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=730,ZONE_OFFSET=3600000,DST_OFFSET=0]]
>>
>> ----- Property [Pipeline.ConsumerMEP] -->
>> [http://www.w3.org/2004/08/wsdl/in-only]
>> ----- Property [org.apache.servicemix.correlationid] -->
>> [ID:boccalon-1684-1166781393627-9:2]
>> ----- Property [org.apache.servicemix.senderEndpoint] -->
>> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
>>
>> ============================ Exchange
>> ==================================
>> MEP: org.apache.servicemix.jbi.messaging.InOutImpl
>> Id & status: ID:boccalon-1684-1166781393627-8:2 Active
>> Sender:
>> {http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
>>
>> Service: {http://servicemix.org/cheese}myGenericEnricherEnricherHttp
>> Endpoint:
>> ServiceEndpoint[service={http://servicemix.org/cheese}myGenericEnricherEnricherHttp,endpoint=myGenericEnricherEnricherHttp]
>>
>> Role: javax.jbi.messaging.MessageExchange$Role@8ff9a7
>> Interfacename: null
>> Operation: null
>> ----- Properties
>> ----- Property [org.apache.servicemix.flow] --> [Seda]
>> ----- Property
>> [Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
>>
>> --> [ID:boccalon-1684-1166781393627-9:2]
>> ----- Property [Pipeline.Transformer] --> [true]
>> ----- Property [org.apache.servicemix.datestamp] -->
>> [java.util.GregorianCalendar[time=1166781979730,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=730,ZONE_OFFSET=3600000,DST_OFFSET=0]]
>>
>> ----- Property [Pipeline.ConsumerMEP] -->
>> [http://www.w3.org/2004/08/wsdl/in-only]
>> ----- Property [org.apache.servicemix.correlationid] -->
>> [ID:boccalon-1684-1166781393627-9:2]
>> ----- Property [org.apache.servicemix.senderEndpoint] -->
>> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
>>
>>
>>
>> You can see that the correlation id is mantained.
>> But in the messages below there is a new correlation id.
>>
>> ============================ Exchange
>> ==================================
>> MEP: org.apache.servicemix.jbi.messaging.InOnlyImpl
>> Id & status: ID:boccalon-1684-1166781393627-8:3 Active
>> Sender:
>> {http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
>>
>> Service: {http://servicemix.org/cheese}myScreenOutputEnricher
>> Endpoint: null
>> Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
>> Interfacename: null
>> Operation: null
>> ----- Properties
>> ----- Property
>> [Pipeline.Transformer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
>>
>> --> [ID:boccalon-1684-1166781393627-8:2]
>> ----- Property
>> [Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
>>
>> --> [ID:boccalon-1684-1166781393627-9:2]
>> ----- Property [org.apache.servicemix.datestamp] -->
>> [java.util.GregorianCalendar[time=1166781980021,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=20,MILLISECOND=21,ZONE_OFFSET=3600000,DST_OFFSET=0]]
>>
>> ----- Property [org.apache.servicemix.correlationid] -->
>> [ID:boccalon-1684-1166781393627-8:3]
>> ----- Property [org.apache.servicemix.senderEndpoint] -->
>> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <arricchisciAnagraficaResponse xmlns="http://soa.eng.it"
>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <arricchisciAnagraficaReturn>
>> <nome>Andrea</nome>
>> <cognome>scamuzzo</cognome>
>> <indirizzo>Corso Stati Uniti 23</indirizzo>
>> <citta>Ferentino</citta>
>> </arricchisciAnagraficaReturn>
>> </arricchisciAnagraficaResponse>
>>
>> The messages below the last one are only the DONE messages, so I omit
>> them.
>>
>> I hope this can help you.
>>
>> Regards
>> Gianfranco Boccalon
>>
>>
>> Guillaume Nodet ha scritto:
>> > What I don't understand is why the correlation id is not
>> > forwarded in asynchronous mode. The modifications in
>> > the AsyncBaseLifecycle should ensure that.
>> > Could you debug and see what happens ?
>> >
>> > On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
>> >> Guillaume,
>> >>
>> >> it's true, I'm working on the same team of Gianfranco that has raised
>> >> the Jira issue about the
>> >> introduction of correlation id.
>> >>
>> >> At the moment we're working on the 3.0 ServiceMix code base with the
>> >> patched classes to use
>> >> the correlation id.
>> >>
>> >> We're using the 3.0 version because we need to work on a stable
>> >> release, so we're trying to solve
>> >> the problem of the Pipeline component on the 3.0 codebase.
>> >>
>> >> Cheers
>> >> Andrea Zoppello
>> >>
>> >> Guillaume Nodet ha scritto:
>> >> > Which correlation id are you refering to ? It was only introduced
>> >> > in 3.1 a few weeks ago ...
>> >> >
>> >> > On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
>> >> >> Hi Guillaume,
>> >> >>
>> >> >> We are working on ServiceMix 3.0 and I suppose that the classes
>> >> >> ProviderEndpoint and EndpointDeliveryChannel were introduced in
>> >> >> ServiceMix 3.1.
>> >> >> The problem, however, happens in asynchronous mode. We didnt try
>> >> >> synchronous mode.
>> >> >>
>> >> >> Cheers
>> >> >>
>> >> >> Andrea Zoppello
>> >> >>
>> >> >>
>> >> >> Guillaume Nodet ha scritto:
>> >> >> > I've refactored the EIP endpoints to now extends the
>> >> ProviderEndpoint
>> >> >> > class (this should have been done earlier btw).
>> >> >> > Would you mind creating a patch on servicemix-common so that
>> >> >> > the call to EndpointDeliveryChannel#sendSync would behave the
>> same
>> >> >> > way than the send method (delegate to a method in
>> >> AsyncBaseLifeCycle)
>> >> >> > so that the correct properties could be set (correlationId,
>> sender
>> >> >> > endpoint) ?
>> >> >> >
>> >> >> >
>> >> >> > On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
>> >> >> >> I don't understand why a new correlation id is created.
>> >> >> >> If the pipeline receives an exchange with a correlationId,
>> >> >> >> when it sends the exchange to the transformer, the
>> correlationId
>> >> >> >> should be propagated, and the same should be true for
>> >> >> >> the end target.
>> >> >> >> However if the synchronous mode is used for the pipeline,
>> >> >> >> the correlationId will not be set for the outbound message
>> >> >> >> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
>> >> >> >>
>> >> >> >> Is that the behavior you experience ?
>> >> >> >>
>> >> >> >> If yes, I think it should be solved by changing the EIPEndpoint
>> >> >> >> to extend ProviderEndpoint (from servicemix-common) and
>> >> >> >> go through the sendConsumerExchange even when sendSync is
>> >> >> >> called. This way, the correct behavior would be used for all
>> >> >> >> components.
>> >> >> >>
>> >> >> >> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
>> >> >> >> > Hi all,
>> >> >> >> > this question is related to the change with id SM-751 on
>> Jira.
>> >> >> >> > I tried a simple process composed in this way: HTTP
>> BC->PIPELINE
>> >> >> (that
>> >> >> >> > sends a message to another HTTP BC to invoke an external
>> >> >> >> > WebService)->Screen BC.
>> >> >> >> > The problem is related to the propagation of correlation id,
>> >> >> generated
>> >> >> >> > by the first HTTP BC.
>> >> >> >> > The correlation id is propagated in the right way until the
>> >> message
>> >> >> >> sent
>> >> >> >> > by PIPELINE to Screen BC: in this case a new correlation
>> id is
>> >> >> >> > generated, and this is not the right behaviour.
>> >> >> >> >
>> >> >> >> > The problem is in the method processAsync that handle the
>> first
>> >> >> >> message
>> >> >> >> > exchange for the pipeline: in this method the utility method
>> >> >> >> > MessageUtil.transferOutToIn(exchange, me) is used to transfer
>> >> some
>> >> >> >> > properties from the source message to the destination
>> message.
>> >> >> >> > The problem is that also some properties from the source
>> message
>> >> >> >> > exchange (not only message) have to be copied in the
>> destination
>> >> >> >> message
>> >> >> >> > exchange: in our case the property is the correlation id.
>> >> >> >> >
>> >> >> >> > So I changed the class MessageUtil adding a method
>> >> >> >> > copyExchangeProperties that I use in all transferXXToYY
>> methods
>> >> >> that
>> >> >> >> > works with Message Exchanges.
>> >> >> >> > In my implementation I copied only the correlation Id because
>> >> i saw
>> >> >> >> that
>> >> >> >> > copying all properties give some problems.
>> >> >> >> >
>> >> >> >> > With this patch all seems work properly.
>> >> >> >> > Is this the right way to solve the problem ?
>> >> >> >> > Should I raise a Jira about this ?
>> >> >> >> >
>> >> >> >> > Thanks
>> >> >> >> >
>> >> >> >> > Andrea Zoppello
>> >> >> >> > Engineering Ing. Informatica
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Cheers,
>> >> >> >> Guillaume Nodet
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Correlation Id in Pipeline component
Posted by Guillaume Nodet <gn...@gmail.com>.
I have just tested with the junit PipelineTest#testInOut test
and it works fine: the correlationId is set when the exchange comes
to the receiver target. As you are using a patched 3.0 version,
I would suggest to check the code in AsyncBaseLifeCycle
with the one in 3.1.
Note that the behavior your see when at your breakpoint is correct,
as the correlationId will be set when the send method is called.
This method delegates to the BaseLifeCycle#sendConsumerExchange
which will correctly set the correlationId.
On 12/22/06, Gianfranco Boccalon <gb...@tiscali.it> wrote:
> I debug the execution, so I can send you some details.
>
> The entire message flow is the following:
> 1. HTTP BC->ENRICHER (PIPELINE)
> 2. ENRICHER->HTTP BC FOR ENRICHER
> 2.1 Invocation of external web service by HTTP BC FOR ENRICHER
> 3. HTTP BC FOR ENRICHER->ENRICHER
> 4. ENRICHER->SCREEN BC
>
> The problem arise in step 4: here a new correlation id is created
> because the exchange sent doesnt contain the correlation id of the
> previous exchanges.
>
> You can see the reason from this stack trace:
> Thread [Thread-31] (Suspended (breakpoint at line 85 in MessageUtil))
> MessageUtil.transferOutToIn(MessageExchange, MessageExchange) line:
> 85
> Pipeline.processAsync(MessageExchange) line: 288
> Pipeline(EIPEndpoint).process(MessageExchange) line: 241
> EIPLifeCycle(AsyncBaseLifeCycle).processExchange(MessageExchange)
> line: 447
> EIPLifeCycle(BaseLifeCycle).onMessageExchange(MessageExchange) line:
> 43
> DeliveryChannelImpl.processInBound(MessageExchangeImpl) line: 624
> SedaFlow(AbstractFlow).doRouting(MessageExchangeImpl) line: 169
> SedaFlow.doRouting(MessageExchangeImpl) line: 177
> SedaQueue$1.run() line: 227
> WorkerContext.run() line: 291
> PooledExecutor$Worker.run() line: not available
> Thread.run() line: 595
>
> The method transferOutToIn copy only message properties from source
> message to destination message, it doesnt copy the message exchanges
> properties from the source to destination.
> I remind you that we are using ServiceMix 3.0.
>
> Here you can see a trace of messages until step 3 (included).
>
> ============================ Exchange ==================================
> MEP: org.apache.servicemix.jbi.messaging.InOnlyImpl
> Id & status: ID:boccalon-1684-1166781393627-9:2 Active
> Sender:
> {http://servicemix.org/cheese}myGenericEnricherEnricher:myWebServiceEnricher
> Service: {http://servicemix.org/cheese}myGenericEnricherEnricher
> Endpoint: null
> Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
> Interfacename: null
> Operation: {http://soa.eng.it}arricchisciAnagrafica
> ----- Properties
> ----- Property [org.apache.servicemix.datestamp] -->
> [java.util.GregorianCalendar[time=1166781979680,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=680,ZONE_OFFSET=3600000,DST_OFFSET=0]]
> ----- Property [org.apache.servicemix.correlationid] -->
> [ID:boccalon-1684-1166781393627-9:2]
> ----- Property [org.apache.servicemix.senderEndpoint] -->
> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myWebServiceEnricher]
> ============================ Exchange ==================================
> MEP: org.apache.servicemix.jbi.messaging.InOutImpl
> Id & status: ID:boccalon-1684-1166781393627-8:2 Active
> Sender:
> {http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
> Service: {http://servicemix.org/cheese}myGenericEnricherEnricherHttp
> Endpoint: null
> Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
> Interfacename: null
> Operation: null
> ----- Properties
> ----- Property
> [Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
> --> [ID:boccalon-1684-1166781393627-9:2]
> ----- Property [Pipeline.Transformer] --> [true]
> ----- Property [org.apache.servicemix.datestamp] -->
> [java.util.GregorianCalendar[time=1166781979730,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=730,ZONE_OFFSET=3600000,DST_OFFSET=0]]
> ----- Property [Pipeline.ConsumerMEP] -->
> [http://www.w3.org/2004/08/wsdl/in-only]
> ----- Property [org.apache.servicemix.correlationid] -->
> [ID:boccalon-1684-1166781393627-9:2]
> ----- Property [org.apache.servicemix.senderEndpoint] -->
> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
> ============================ Exchange ==================================
> MEP: org.apache.servicemix.jbi.messaging.InOutImpl
> Id & status: ID:boccalon-1684-1166781393627-8:2 Active
> Sender:
> {http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
> Service: {http://servicemix.org/cheese}myGenericEnricherEnricherHttp
> Endpoint:
> ServiceEndpoint[service={http://servicemix.org/cheese}myGenericEnricherEnricherHttp,endpoint=myGenericEnricherEnricherHttp]
> Role: javax.jbi.messaging.MessageExchange$Role@8ff9a7
> Interfacename: null
> Operation: null
> ----- Properties
> ----- Property [org.apache.servicemix.flow] --> [Seda]
> ----- Property
> [Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
> --> [ID:boccalon-1684-1166781393627-9:2]
> ----- Property [Pipeline.Transformer] --> [true]
> ----- Property [org.apache.servicemix.datestamp] -->
> [java.util.GregorianCalendar[time=1166781979730,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=730,ZONE_OFFSET=3600000,DST_OFFSET=0]]
> ----- Property [Pipeline.ConsumerMEP] -->
> [http://www.w3.org/2004/08/wsdl/in-only]
> ----- Property [org.apache.servicemix.correlationid] -->
> [ID:boccalon-1684-1166781393627-9:2]
> ----- Property [org.apache.servicemix.senderEndpoint] -->
> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
>
>
> You can see that the correlation id is mantained.
> But in the messages below there is a new correlation id.
>
> ============================ Exchange ==================================
> MEP: org.apache.servicemix.jbi.messaging.InOnlyImpl
> Id & status: ID:boccalon-1684-1166781393627-8:3 Active
> Sender:
> {http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
> Service: {http://servicemix.org/cheese}myScreenOutputEnricher
> Endpoint: null
> Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
> Interfacename: null
> Operation: null
> ----- Properties
> ----- Property
> [Pipeline.Transformer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
> --> [ID:boccalon-1684-1166781393627-8:2]
> ----- Property
> [Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
> --> [ID:boccalon-1684-1166781393627-9:2]
> ----- Property [org.apache.servicemix.datestamp] -->
> [java.util.GregorianCalendar[time=1166781980021,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=20,MILLISECOND=21,ZONE_OFFSET=3600000,DST_OFFSET=0]]
> ----- Property [org.apache.servicemix.correlationid] -->
> [ID:boccalon-1684-1166781393627-8:3]
> ----- Property [org.apache.servicemix.senderEndpoint] -->
> [{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
> <?xml version="1.0" encoding="UTF-8"?>
> <arricchisciAnagraficaResponse xmlns="http://soa.eng.it"
> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <arricchisciAnagraficaReturn>
> <nome>Andrea</nome>
> <cognome>scamuzzo</cognome>
> <indirizzo>Corso Stati Uniti 23</indirizzo>
> <citta>Ferentino</citta>
> </arricchisciAnagraficaReturn>
> </arricchisciAnagraficaResponse>
>
> The messages below the last one are only the DONE messages, so I omit them.
>
> I hope this can help you.
>
> Regards
> Gianfranco Boccalon
>
>
> Guillaume Nodet ha scritto:
> > What I don't understand is why the correlation id is not
> > forwarded in asynchronous mode. The modifications in
> > the AsyncBaseLifecycle should ensure that.
> > Could you debug and see what happens ?
> >
> > On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
> >> Guillaume,
> >>
> >> it's true, I'm working on the same team of Gianfranco that has raised
> >> the Jira issue about the
> >> introduction of correlation id.
> >>
> >> At the moment we're working on the 3.0 ServiceMix code base with the
> >> patched classes to use
> >> the correlation id.
> >>
> >> We're using the 3.0 version because we need to work on a stable
> >> release, so we're trying to solve
> >> the problem of the Pipeline component on the 3.0 codebase.
> >>
> >> Cheers
> >> Andrea Zoppello
> >>
> >> Guillaume Nodet ha scritto:
> >> > Which correlation id are you refering to ? It was only introduced
> >> > in 3.1 a few weeks ago ...
> >> >
> >> > On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
> >> >> Hi Guillaume,
> >> >>
> >> >> We are working on ServiceMix 3.0 and I suppose that the classes
> >> >> ProviderEndpoint and EndpointDeliveryChannel were introduced in
> >> >> ServiceMix 3.1.
> >> >> The problem, however, happens in asynchronous mode. We didnt try
> >> >> synchronous mode.
> >> >>
> >> >> Cheers
> >> >>
> >> >> Andrea Zoppello
> >> >>
> >> >>
> >> >> Guillaume Nodet ha scritto:
> >> >> > I've refactored the EIP endpoints to now extends the
> >> ProviderEndpoint
> >> >> > class (this should have been done earlier btw).
> >> >> > Would you mind creating a patch on servicemix-common so that
> >> >> > the call to EndpointDeliveryChannel#sendSync would behave the same
> >> >> > way than the send method (delegate to a method in
> >> AsyncBaseLifeCycle)
> >> >> > so that the correct properties could be set (correlationId, sender
> >> >> > endpoint) ?
> >> >> >
> >> >> >
> >> >> > On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >> >> >> I don't understand why a new correlation id is created.
> >> >> >> If the pipeline receives an exchange with a correlationId,
> >> >> >> when it sends the exchange to the transformer, the correlationId
> >> >> >> should be propagated, and the same should be true for
> >> >> >> the end target.
> >> >> >> However if the synchronous mode is used for the pipeline,
> >> >> >> the correlationId will not be set for the outbound message
> >> >> >> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
> >> >> >>
> >> >> >> Is that the behavior you experience ?
> >> >> >>
> >> >> >> If yes, I think it should be solved by changing the EIPEndpoint
> >> >> >> to extend ProviderEndpoint (from servicemix-common) and
> >> >> >> go through the sendConsumerExchange even when sendSync is
> >> >> >> called. This way, the correct behavior would be used for all
> >> >> >> components.
> >> >> >>
> >> >> >> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
> >> >> >> > Hi all,
> >> >> >> > this question is related to the change with id SM-751 on Jira.
> >> >> >> > I tried a simple process composed in this way: HTTP BC->PIPELINE
> >> >> (that
> >> >> >> > sends a message to another HTTP BC to invoke an external
> >> >> >> > WebService)->Screen BC.
> >> >> >> > The problem is related to the propagation of correlation id,
> >> >> generated
> >> >> >> > by the first HTTP BC.
> >> >> >> > The correlation id is propagated in the right way until the
> >> message
> >> >> >> sent
> >> >> >> > by PIPELINE to Screen BC: in this case a new correlation id is
> >> >> >> > generated, and this is not the right behaviour.
> >> >> >> >
> >> >> >> > The problem is in the method processAsync that handle the first
> >> >> >> message
> >> >> >> > exchange for the pipeline: in this method the utility method
> >> >> >> > MessageUtil.transferOutToIn(exchange, me) is used to transfer
> >> some
> >> >> >> > properties from the source message to the destination message.
> >> >> >> > The problem is that also some properties from the source message
> >> >> >> > exchange (not only message) have to be copied in the destination
> >> >> >> message
> >> >> >> > exchange: in our case the property is the correlation id.
> >> >> >> >
> >> >> >> > So I changed the class MessageUtil adding a method
> >> >> >> > copyExchangeProperties that I use in all transferXXToYY methods
> >> >> that
> >> >> >> > works with Message Exchanges.
> >> >> >> > In my implementation I copied only the correlation Id because
> >> i saw
> >> >> >> that
> >> >> >> > copying all properties give some problems.
> >> >> >> >
> >> >> >> > With this patch all seems work properly.
> >> >> >> > Is this the right way to solve the problem ?
> >> >> >> > Should I raise a Jira about this ?
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > Andrea Zoppello
> >> >> >> > Engineering Ing. Informatica
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Cheers,
> >> >> >> Guillaume Nodet
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Re: Correlation Id in Pipeline component
Posted by Gianfranco Boccalon <gb...@tiscali.it>.
I debug the execution, so I can send you some details.
The entire message flow is the following:
1. HTTP BC->ENRICHER (PIPELINE)
2. ENRICHER->HTTP BC FOR ENRICHER
2.1 Invocation of external web service by HTTP BC FOR ENRICHER
3. HTTP BC FOR ENRICHER->ENRICHER
4. ENRICHER->SCREEN BC
The problem arise in step 4: here a new correlation id is created
because the exchange sent doesnt contain the correlation id of the
previous exchanges.
You can see the reason from this stack trace:
Thread [Thread-31] (Suspended (breakpoint at line 85 in MessageUtil))
MessageUtil.transferOutToIn(MessageExchange, MessageExchange) line:
85
Pipeline.processAsync(MessageExchange) line: 288
Pipeline(EIPEndpoint).process(MessageExchange) line: 241
EIPLifeCycle(AsyncBaseLifeCycle).processExchange(MessageExchange)
line: 447
EIPLifeCycle(BaseLifeCycle).onMessageExchange(MessageExchange) line:
43
DeliveryChannelImpl.processInBound(MessageExchangeImpl) line: 624
SedaFlow(AbstractFlow).doRouting(MessageExchangeImpl) line: 169
SedaFlow.doRouting(MessageExchangeImpl) line: 177
SedaQueue$1.run() line: 227
WorkerContext.run() line: 291
PooledExecutor$Worker.run() line: not available
Thread.run() line: 595
The method transferOutToIn copy only message properties from source
message to destination message, it doesnt copy the message exchanges
properties from the source to destination.
I remind you that we are using ServiceMix 3.0.
Here you can see a trace of messages until step 3 (included).
============================ Exchange ==================================
MEP: org.apache.servicemix.jbi.messaging.InOnlyImpl
Id & status: ID:boccalon-1684-1166781393627-9:2 Active
Sender:
{http://servicemix.org/cheese}myGenericEnricherEnricher:myWebServiceEnricher
Service: {http://servicemix.org/cheese}myGenericEnricherEnricher
Endpoint: null
Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
Interfacename: null
Operation: {http://soa.eng.it}arricchisciAnagrafica
----- Properties
----- Property [org.apache.servicemix.datestamp] -->
[java.util.GregorianCalendar[time=1166781979680,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=680,ZONE_OFFSET=3600000,DST_OFFSET=0]]
----- Property [org.apache.servicemix.correlationid] -->
[ID:boccalon-1684-1166781393627-9:2]
----- Property [org.apache.servicemix.senderEndpoint] -->
[{http://servicemix.org/cheese}myGenericEnricherEnricher:myWebServiceEnricher]
============================ Exchange ==================================
MEP: org.apache.servicemix.jbi.messaging.InOutImpl
Id & status: ID:boccalon-1684-1166781393627-8:2 Active
Sender:
{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
Service: {http://servicemix.org/cheese}myGenericEnricherEnricherHttp
Endpoint: null
Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
Interfacename: null
Operation: null
----- Properties
----- Property
[Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
--> [ID:boccalon-1684-1166781393627-9:2]
----- Property [Pipeline.Transformer] --> [true]
----- Property [org.apache.servicemix.datestamp] -->
[java.util.GregorianCalendar[time=1166781979730,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=730,ZONE_OFFSET=3600000,DST_OFFSET=0]]
----- Property [Pipeline.ConsumerMEP] -->
[http://www.w3.org/2004/08/wsdl/in-only]
----- Property [org.apache.servicemix.correlationid] -->
[ID:boccalon-1684-1166781393627-9:2]
----- Property [org.apache.servicemix.senderEndpoint] -->
[{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
============================ Exchange ==================================
MEP: org.apache.servicemix.jbi.messaging.InOutImpl
Id & status: ID:boccalon-1684-1166781393627-8:2 Active
Sender:
{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
Service: {http://servicemix.org/cheese}myGenericEnricherEnricherHttp
Endpoint:
ServiceEndpoint[service={http://servicemix.org/cheese}myGenericEnricherEnricherHttp,endpoint=myGenericEnricherEnricherHttp]
Role: javax.jbi.messaging.MessageExchange$Role@8ff9a7
Interfacename: null
Operation: null
----- Properties
----- Property [org.apache.servicemix.flow] --> [Seda]
----- Property
[Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
--> [ID:boccalon-1684-1166781393627-9:2]
----- Property [Pipeline.Transformer] --> [true]
----- Property [org.apache.servicemix.datestamp] -->
[java.util.GregorianCalendar[time=1166781979730,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=19,MILLISECOND=730,ZONE_OFFSET=3600000,DST_OFFSET=0]]
----- Property [Pipeline.ConsumerMEP] -->
[http://www.w3.org/2004/08/wsdl/in-only]
----- Property [org.apache.servicemix.correlationid] -->
[ID:boccalon-1684-1166781393627-9:2]
----- Property [org.apache.servicemix.senderEndpoint] -->
[{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
You can see that the correlation id is mantained.
But in the messages below there is a new correlation id.
============================ Exchange ==================================
MEP: org.apache.servicemix.jbi.messaging.InOnlyImpl
Id & status: ID:boccalon-1684-1166781393627-8:3 Active
Sender:
{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher
Service: {http://servicemix.org/cheese}myScreenOutputEnricher
Endpoint: null
Role: javax.jbi.messaging.MessageExchange$Role@1f66f50
Interfacename: null
Operation: null
----- Properties
----- Property
[Pipeline.Transformer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
--> [ID:boccalon-1684-1166781393627-8:2]
----- Property
[Pipeline.Consumer.{http://servicemix.org/cheese}myGenericEnricherEnricher.myGenericEnricherEnricher]
--> [ID:boccalon-1684-1166781393627-9:2]
----- Property [org.apache.servicemix.datestamp] -->
[java.util.GregorianCalendar[time=1166781980021,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2006,MONTH=11,WEEK_OF_YEAR=51,WEEK_OF_MONTH=3,DAY_OF_MONTH=22,DAY_OF_YEAR=356,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=4,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=6,SECOND=20,MILLISECOND=21,ZONE_OFFSET=3600000,DST_OFFSET=0]]
----- Property [org.apache.servicemix.correlationid] -->
[ID:boccalon-1684-1166781393627-8:3]
----- Property [org.apache.servicemix.senderEndpoint] -->
[{http://servicemix.org/cheese}myGenericEnricherEnricher:myGenericEnricherEnricher]
<?xml version="1.0" encoding="UTF-8"?>
<arricchisciAnagraficaResponse xmlns="http://soa.eng.it"
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<arricchisciAnagraficaReturn>
<nome>Andrea</nome>
<cognome>scamuzzo</cognome>
<indirizzo>Corso Stati Uniti 23</indirizzo>
<citta>Ferentino</citta>
</arricchisciAnagraficaReturn>
</arricchisciAnagraficaResponse>
The messages below the last one are only the DONE messages, so I omit them.
I hope this can help you.
Regards
Gianfranco Boccalon
Guillaume Nodet ha scritto:
> What I don't understand is why the correlation id is not
> forwarded in asynchronous mode. The modifications in
> the AsyncBaseLifecycle should ensure that.
> Could you debug and see what happens ?
>
> On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
>> Guillaume,
>>
>> it's true, I'm working on the same team of Gianfranco that has raised
>> the Jira issue about the
>> introduction of correlation id.
>>
>> At the moment we're working on the 3.0 ServiceMix code base with the
>> patched classes to use
>> the correlation id.
>>
>> We're using the 3.0 version because we need to work on a stable
>> release, so we're trying to solve
>> the problem of the Pipeline component on the 3.0 codebase.
>>
>> Cheers
>> Andrea Zoppello
>>
>> Guillaume Nodet ha scritto:
>> > Which correlation id are you refering to ? It was only introduced
>> > in 3.1 a few weeks ago ...
>> >
>> > On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
>> >> Hi Guillaume,
>> >>
>> >> We are working on ServiceMix 3.0 and I suppose that the classes
>> >> ProviderEndpoint and EndpointDeliveryChannel were introduced in
>> >> ServiceMix 3.1.
>> >> The problem, however, happens in asynchronous mode. We didnt try
>> >> synchronous mode.
>> >>
>> >> Cheers
>> >>
>> >> Andrea Zoppello
>> >>
>> >>
>> >> Guillaume Nodet ha scritto:
>> >> > I've refactored the EIP endpoints to now extends the
>> ProviderEndpoint
>> >> > class (this should have been done earlier btw).
>> >> > Would you mind creating a patch on servicemix-common so that
>> >> > the call to EndpointDeliveryChannel#sendSync would behave the same
>> >> > way than the send method (delegate to a method in
>> AsyncBaseLifeCycle)
>> >> > so that the correct properties could be set (correlationId, sender
>> >> > endpoint) ?
>> >> >
>> >> >
>> >> > On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
>> >> >> I don't understand why a new correlation id is created.
>> >> >> If the pipeline receives an exchange with a correlationId,
>> >> >> when it sends the exchange to the transformer, the correlationId
>> >> >> should be propagated, and the same should be true for
>> >> >> the end target.
>> >> >> However if the synchronous mode is used for the pipeline,
>> >> >> the correlationId will not be set for the outbound message
>> >> >> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
>> >> >>
>> >> >> Is that the behavior you experience ?
>> >> >>
>> >> >> If yes, I think it should be solved by changing the EIPEndpoint
>> >> >> to extend ProviderEndpoint (from servicemix-common) and
>> >> >> go through the sendConsumerExchange even when sendSync is
>> >> >> called. This way, the correct behavior would be used for all
>> >> >> components.
>> >> >>
>> >> >> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
>> >> >> > Hi all,
>> >> >> > this question is related to the change with id SM-751 on Jira.
>> >> >> > I tried a simple process composed in this way: HTTP BC->PIPELINE
>> >> (that
>> >> >> > sends a message to another HTTP BC to invoke an external
>> >> >> > WebService)->Screen BC.
>> >> >> > The problem is related to the propagation of correlation id,
>> >> generated
>> >> >> > by the first HTTP BC.
>> >> >> > The correlation id is propagated in the right way until the
>> message
>> >> >> sent
>> >> >> > by PIPELINE to Screen BC: in this case a new correlation id is
>> >> >> > generated, and this is not the right behaviour.
>> >> >> >
>> >> >> > The problem is in the method processAsync that handle the first
>> >> >> message
>> >> >> > exchange for the pipeline: in this method the utility method
>> >> >> > MessageUtil.transferOutToIn(exchange, me) is used to transfer
>> some
>> >> >> > properties from the source message to the destination message.
>> >> >> > The problem is that also some properties from the source message
>> >> >> > exchange (not only message) have to be copied in the destination
>> >> >> message
>> >> >> > exchange: in our case the property is the correlation id.
>> >> >> >
>> >> >> > So I changed the class MessageUtil adding a method
>> >> >> > copyExchangeProperties that I use in all transferXXToYY methods
>> >> that
>> >> >> > works with Message Exchanges.
>> >> >> > In my implementation I copied only the correlation Id because
>> i saw
>> >> >> that
>> >> >> > copying all properties give some problems.
>> >> >> >
>> >> >> > With this patch all seems work properly.
>> >> >> > Is this the right way to solve the problem ?
>> >> >> > Should I raise a Jira about this ?
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > Andrea Zoppello
>> >> >> > Engineering Ing. Informatica
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Cheers,
>> >> >> Guillaume Nodet
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Correlation Id in Pipeline component
Posted by Guillaume Nodet <gn...@gmail.com>.
What I don't understand is why the correlation id is not
forwarded in asynchronous mode. The modifications in
the AsyncBaseLifecycle should ensure that.
Could you debug and see what happens ?
On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
> Guillaume,
>
> it's true, I'm working on the same team of Gianfranco that has raised
> the Jira issue about the
> introduction of correlation id.
>
> At the moment we're working on the 3.0 ServiceMix code base with the
> patched classes to use
> the correlation id.
>
> We're using the 3.0 version because we need to work on a stable
> release, so we're trying to solve
> the problem of the Pipeline component on the 3.0 codebase.
>
> Cheers
> Andrea Zoppello
>
> Guillaume Nodet ha scritto:
> > Which correlation id are you refering to ? It was only introduced
> > in 3.1 a few weeks ago ...
> >
> > On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
> >> Hi Guillaume,
> >>
> >> We are working on ServiceMix 3.0 and I suppose that the classes
> >> ProviderEndpoint and EndpointDeliveryChannel were introduced in
> >> ServiceMix 3.1.
> >> The problem, however, happens in asynchronous mode. We didnt try
> >> synchronous mode.
> >>
> >> Cheers
> >>
> >> Andrea Zoppello
> >>
> >>
> >> Guillaume Nodet ha scritto:
> >> > I've refactored the EIP endpoints to now extends the ProviderEndpoint
> >> > class (this should have been done earlier btw).
> >> > Would you mind creating a patch on servicemix-common so that
> >> > the call to EndpointDeliveryChannel#sendSync would behave the same
> >> > way than the send method (delegate to a method in AsyncBaseLifeCycle)
> >> > so that the correct properties could be set (correlationId, sender
> >> > endpoint) ?
> >> >
> >> >
> >> > On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >> >> I don't understand why a new correlation id is created.
> >> >> If the pipeline receives an exchange with a correlationId,
> >> >> when it sends the exchange to the transformer, the correlationId
> >> >> should be propagated, and the same should be true for
> >> >> the end target.
> >> >> However if the synchronous mode is used for the pipeline,
> >> >> the correlationId will not be set for the outbound message
> >> >> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
> >> >>
> >> >> Is that the behavior you experience ?
> >> >>
> >> >> If yes, I think it should be solved by changing the EIPEndpoint
> >> >> to extend ProviderEndpoint (from servicemix-common) and
> >> >> go through the sendConsumerExchange even when sendSync is
> >> >> called. This way, the correct behavior would be used for all
> >> >> components.
> >> >>
> >> >> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
> >> >> > Hi all,
> >> >> > this question is related to the change with id SM-751 on Jira.
> >> >> > I tried a simple process composed in this way: HTTP BC->PIPELINE
> >> (that
> >> >> > sends a message to another HTTP BC to invoke an external
> >> >> > WebService)->Screen BC.
> >> >> > The problem is related to the propagation of correlation id,
> >> generated
> >> >> > by the first HTTP BC.
> >> >> > The correlation id is propagated in the right way until the message
> >> >> sent
> >> >> > by PIPELINE to Screen BC: in this case a new correlation id is
> >> >> > generated, and this is not the right behaviour.
> >> >> >
> >> >> > The problem is in the method processAsync that handle the first
> >> >> message
> >> >> > exchange for the pipeline: in this method the utility method
> >> >> > MessageUtil.transferOutToIn(exchange, me) is used to transfer some
> >> >> > properties from the source message to the destination message.
> >> >> > The problem is that also some properties from the source message
> >> >> > exchange (not only message) have to be copied in the destination
> >> >> message
> >> >> > exchange: in our case the property is the correlation id.
> >> >> >
> >> >> > So I changed the class MessageUtil adding a method
> >> >> > copyExchangeProperties that I use in all transferXXToYY methods
> >> that
> >> >> > works with Message Exchanges.
> >> >> > In my implementation I copied only the correlation Id because i saw
> >> >> that
> >> >> > copying all properties give some problems.
> >> >> >
> >> >> > With this patch all seems work properly.
> >> >> > Is this the right way to solve the problem ?
> >> >> > Should I raise a Jira about this ?
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Andrea Zoppello
> >> >> > Engineering Ing. Informatica
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Cheers,
> >> >> Guillaume Nodet
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Re: Correlation Id in Pipeline component
Posted by Andrea Zoppello <zo...@libero.it>.
Guillaume,
it's true, I'm working on the same team of Gianfranco that has raised
the Jira issue about the
introduction of correlation id.
At the moment we're working on the 3.0 ServiceMix code base with the
patched classes to use
the correlation id.
We're using the 3.0 version because we need to work on a stable
release, so we're trying to solve
the problem of the Pipeline component on the 3.0 codebase.
Cheers
Andrea Zoppello
Guillaume Nodet ha scritto:
> Which correlation id are you refering to ? It was only introduced
> in 3.1 a few weeks ago ...
>
> On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
>> Hi Guillaume,
>>
>> We are working on ServiceMix 3.0 and I suppose that the classes
>> ProviderEndpoint and EndpointDeliveryChannel were introduced in
>> ServiceMix 3.1.
>> The problem, however, happens in asynchronous mode. We didnt try
>> synchronous mode.
>>
>> Cheers
>>
>> Andrea Zoppello
>>
>>
>> Guillaume Nodet ha scritto:
>> > I've refactored the EIP endpoints to now extends the ProviderEndpoint
>> > class (this should have been done earlier btw).
>> > Would you mind creating a patch on servicemix-common so that
>> > the call to EndpointDeliveryChannel#sendSync would behave the same
>> > way than the send method (delegate to a method in AsyncBaseLifeCycle)
>> > so that the correct properties could be set (correlationId, sender
>> > endpoint) ?
>> >
>> >
>> > On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
>> >> I don't understand why a new correlation id is created.
>> >> If the pipeline receives an exchange with a correlationId,
>> >> when it sends the exchange to the transformer, the correlationId
>> >> should be propagated, and the same should be true for
>> >> the end target.
>> >> However if the synchronous mode is used for the pipeline,
>> >> the correlationId will not be set for the outbound message
>> >> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
>> >>
>> >> Is that the behavior you experience ?
>> >>
>> >> If yes, I think it should be solved by changing the EIPEndpoint
>> >> to extend ProviderEndpoint (from servicemix-common) and
>> >> go through the sendConsumerExchange even when sendSync is
>> >> called. This way, the correct behavior would be used for all
>> >> components.
>> >>
>> >> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
>> >> > Hi all,
>> >> > this question is related to the change with id SM-751 on Jira.
>> >> > I tried a simple process composed in this way: HTTP BC->PIPELINE
>> (that
>> >> > sends a message to another HTTP BC to invoke an external
>> >> > WebService)->Screen BC.
>> >> > The problem is related to the propagation of correlation id,
>> generated
>> >> > by the first HTTP BC.
>> >> > The correlation id is propagated in the right way until the message
>> >> sent
>> >> > by PIPELINE to Screen BC: in this case a new correlation id is
>> >> > generated, and this is not the right behaviour.
>> >> >
>> >> > The problem is in the method processAsync that handle the first
>> >> message
>> >> > exchange for the pipeline: in this method the utility method
>> >> > MessageUtil.transferOutToIn(exchange, me) is used to transfer some
>> >> > properties from the source message to the destination message.
>> >> > The problem is that also some properties from the source message
>> >> > exchange (not only message) have to be copied in the destination
>> >> message
>> >> > exchange: in our case the property is the correlation id.
>> >> >
>> >> > So I changed the class MessageUtil adding a method
>> >> > copyExchangeProperties that I use in all transferXXToYY methods
>> that
>> >> > works with Message Exchanges.
>> >> > In my implementation I copied only the correlation Id because i saw
>> >> that
>> >> > copying all properties give some problems.
>> >> >
>> >> > With this patch all seems work properly.
>> >> > Is this the right way to solve the problem ?
>> >> > Should I raise a Jira about this ?
>> >> >
>> >> > Thanks
>> >> >
>> >> > Andrea Zoppello
>> >> > Engineering Ing. Informatica
>> >> >
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >>
>> >
>> >
>>
>>
>
>
Re: Correlation Id in Pipeline component
Posted by Guillaume Nodet <gn...@gmail.com>.
Which correlation id are you refering to ? It was only introduced
in 3.1 a few weeks ago ...
On 12/21/06, Andrea Zoppello <zo...@libero.it> wrote:
> Hi Guillaume,
>
> We are working on ServiceMix 3.0 and I suppose that the classes
> ProviderEndpoint and EndpointDeliveryChannel were introduced in
> ServiceMix 3.1.
> The problem, however, happens in asynchronous mode. We didnt try
> synchronous mode.
>
> Cheers
>
> Andrea Zoppello
>
>
> Guillaume Nodet ha scritto:
> > I've refactored the EIP endpoints to now extends the ProviderEndpoint
> > class (this should have been done earlier btw).
> > Would you mind creating a patch on servicemix-common so that
> > the call to EndpointDeliveryChannel#sendSync would behave the same
> > way than the send method (delegate to a method in AsyncBaseLifeCycle)
> > so that the correct properties could be set (correlationId, sender
> > endpoint) ?
> >
> >
> > On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >> I don't understand why a new correlation id is created.
> >> If the pipeline receives an exchange with a correlationId,
> >> when it sends the exchange to the transformer, the correlationId
> >> should be propagated, and the same should be true for
> >> the end target.
> >> However if the synchronous mode is used for the pipeline,
> >> the correlationId will not be set for the outbound message
> >> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
> >>
> >> Is that the behavior you experience ?
> >>
> >> If yes, I think it should be solved by changing the EIPEndpoint
> >> to extend ProviderEndpoint (from servicemix-common) and
> >> go through the sendConsumerExchange even when sendSync is
> >> called. This way, the correct behavior would be used for all
> >> components.
> >>
> >> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
> >> > Hi all,
> >> > this question is related to the change with id SM-751 on Jira.
> >> > I tried a simple process composed in this way: HTTP BC->PIPELINE (that
> >> > sends a message to another HTTP BC to invoke an external
> >> > WebService)->Screen BC.
> >> > The problem is related to the propagation of correlation id, generated
> >> > by the first HTTP BC.
> >> > The correlation id is propagated in the right way until the message
> >> sent
> >> > by PIPELINE to Screen BC: in this case a new correlation id is
> >> > generated, and this is not the right behaviour.
> >> >
> >> > The problem is in the method processAsync that handle the first
> >> message
> >> > exchange for the pipeline: in this method the utility method
> >> > MessageUtil.transferOutToIn(exchange, me) is used to transfer some
> >> > properties from the source message to the destination message.
> >> > The problem is that also some properties from the source message
> >> > exchange (not only message) have to be copied in the destination
> >> message
> >> > exchange: in our case the property is the correlation id.
> >> >
> >> > So I changed the class MessageUtil adding a method
> >> > copyExchangeProperties that I use in all transferXXToYY methods that
> >> > works with Message Exchanges.
> >> > In my implementation I copied only the correlation Id because i saw
> >> that
> >> > copying all properties give some problems.
> >> >
> >> > With this patch all seems work properly.
> >> > Is this the right way to solve the problem ?
> >> > Should I raise a Jira about this ?
> >> >
> >> > Thanks
> >> >
> >> > Andrea Zoppello
> >> > Engineering Ing. Informatica
> >> >
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >>
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Re: Correlation Id in Pipeline component
Posted by Andrea Zoppello <zo...@libero.it>.
Hi Guillaume,
We are working on ServiceMix 3.0 and I suppose that the classes
ProviderEndpoint and EndpointDeliveryChannel were introduced in
ServiceMix 3.1.
The problem, however, happens in asynchronous mode. We didnt try
synchronous mode.
Cheers
Andrea Zoppello
Guillaume Nodet ha scritto:
> I've refactored the EIP endpoints to now extends the ProviderEndpoint
> class (this should have been done earlier btw).
> Would you mind creating a patch on servicemix-common so that
> the call to EndpointDeliveryChannel#sendSync would behave the same
> way than the send method (delegate to a method in AsyncBaseLifeCycle)
> so that the correct properties could be set (correlationId, sender
> endpoint) ?
>
>
> On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
>> I don't understand why a new correlation id is created.
>> If the pipeline receives an exchange with a correlationId,
>> when it sends the exchange to the transformer, the correlationId
>> should be propagated, and the same should be true for
>> the end target.
>> However if the synchronous mode is used for the pipeline,
>> the correlationId will not be set for the outbound message
>> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
>>
>> Is that the behavior you experience ?
>>
>> If yes, I think it should be solved by changing the EIPEndpoint
>> to extend ProviderEndpoint (from servicemix-common) and
>> go through the sendConsumerExchange even when sendSync is
>> called. This way, the correct behavior would be used for all
>> components.
>>
>> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
>> > Hi all,
>> > this question is related to the change with id SM-751 on Jira.
>> > I tried a simple process composed in this way: HTTP BC->PIPELINE (that
>> > sends a message to another HTTP BC to invoke an external
>> > WebService)->Screen BC.
>> > The problem is related to the propagation of correlation id, generated
>> > by the first HTTP BC.
>> > The correlation id is propagated in the right way until the message
>> sent
>> > by PIPELINE to Screen BC: in this case a new correlation id is
>> > generated, and this is not the right behaviour.
>> >
>> > The problem is in the method processAsync that handle the first
>> message
>> > exchange for the pipeline: in this method the utility method
>> > MessageUtil.transferOutToIn(exchange, me) is used to transfer some
>> > properties from the source message to the destination message.
>> > The problem is that also some properties from the source message
>> > exchange (not only message) have to be copied in the destination
>> message
>> > exchange: in our case the property is the correlation id.
>> >
>> > So I changed the class MessageUtil adding a method
>> > copyExchangeProperties that I use in all transferXXToYY methods that
>> > works with Message Exchanges.
>> > In my implementation I copied only the correlation Id because i saw
>> that
>> > copying all properties give some problems.
>> >
>> > With this patch all seems work properly.
>> > Is this the right way to solve the problem ?
>> > Should I raise a Jira about this ?
>> >
>> > Thanks
>> >
>> > Andrea Zoppello
>> > Engineering Ing. Informatica
>> >
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>>
>
>
Re: Correlation Id in Pipeline component
Posted by Guillaume Nodet <gn...@gmail.com>.
I've refactored the EIP endpoints to now extends the ProviderEndpoint
class (this should have been done earlier btw).
Would you mind creating a patch on servicemix-common so that
the call to EndpointDeliveryChannel#sendSync would behave the same
way than the send method (delegate to a method in AsyncBaseLifeCycle)
so that the correct properties could be set (correlationId, sender endpoint) ?
On 12/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
> I don't understand why a new correlation id is created.
> If the pipeline receives an exchange with a correlationId,
> when it sends the exchange to the transformer, the correlationId
> should be propagated, and the same should be true for
> the end target.
> However if the synchronous mode is used for the pipeline,
> the correlationId will not be set for the outbound message
> (the AsyncBaseLifeCycle#sendConsumerExchange is not called).
>
> Is that the behavior you experience ?
>
> If yes, I think it should be solved by changing the EIPEndpoint
> to extend ProviderEndpoint (from servicemix-common) and
> go through the sendConsumerExchange even when sendSync is
> called. This way, the correct behavior would be used for all
> components.
>
> On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
> > Hi all,
> > this question is related to the change with id SM-751 on Jira.
> > I tried a simple process composed in this way: HTTP BC->PIPELINE (that
> > sends a message to another HTTP BC to invoke an external
> > WebService)->Screen BC.
> > The problem is related to the propagation of correlation id, generated
> > by the first HTTP BC.
> > The correlation id is propagated in the right way until the message sent
> > by PIPELINE to Screen BC: in this case a new correlation id is
> > generated, and this is not the right behaviour.
> >
> > The problem is in the method processAsync that handle the first message
> > exchange for the pipeline: in this method the utility method
> > MessageUtil.transferOutToIn(exchange, me) is used to transfer some
> > properties from the source message to the destination message.
> > The problem is that also some properties from the source message
> > exchange (not only message) have to be copied in the destination message
> > exchange: in our case the property is the correlation id.
> >
> > So I changed the class MessageUtil adding a method
> > copyExchangeProperties that I use in all transferXXToYY methods that
> > works with Message Exchanges.
> > In my implementation I copied only the correlation Id because i saw that
> > copying all properties give some problems.
> >
> > With this patch all seems work properly.
> > Is this the right way to solve the problem ?
> > Should I raise a Jira about this ?
> >
> > Thanks
> >
> > Andrea Zoppello
> > Engineering Ing. Informatica
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
Re: Correlation Id in Pipeline component
Posted by Guillaume Nodet <gn...@gmail.com>.
I don't understand why a new correlation id is created.
If the pipeline receives an exchange with a correlationId,
when it sends the exchange to the transformer, the correlationId
should be propagated, and the same should be true for
the end target.
However if the synchronous mode is used for the pipeline,
the correlationId will not be set for the outbound message
(the AsyncBaseLifeCycle#sendConsumerExchange is not called).
Is that the behavior you experience ?
If yes, I think it should be solved by changing the EIPEndpoint
to extend ProviderEndpoint (from servicemix-common) and
go through the sendConsumerExchange even when sendSync is
called. This way, the correct behavior would be used for all
components.
On 12/19/06, Andrea Zoppello <zo...@libero.it> wrote:
> Hi all,
> this question is related to the change with id SM-751 on Jira.
> I tried a simple process composed in this way: HTTP BC->PIPELINE (that
> sends a message to another HTTP BC to invoke an external
> WebService)->Screen BC.
> The problem is related to the propagation of correlation id, generated
> by the first HTTP BC.
> The correlation id is propagated in the right way until the message sent
> by PIPELINE to Screen BC: in this case a new correlation id is
> generated, and this is not the right behaviour.
>
> The problem is in the method processAsync that handle the first message
> exchange for the pipeline: in this method the utility method
> MessageUtil.transferOutToIn(exchange, me) is used to transfer some
> properties from the source message to the destination message.
> The problem is that also some properties from the source message
> exchange (not only message) have to be copied in the destination message
> exchange: in our case the property is the correlation id.
>
> So I changed the class MessageUtil adding a method
> copyExchangeProperties that I use in all transferXXToYY methods that
> works with Message Exchanges.
> In my implementation I copied only the correlation Id because i saw that
> copying all properties give some problems.
>
> With this patch all seems work properly.
> Is this the right way to solve the problem ?
> Should I raise a Jira about this ?
>
> Thanks
>
> Andrea Zoppello
> Engineering Ing. Informatica
>
--
Cheers,
Guillaume Nodet