If it works at DEBUG level, but not at WARN level, this means there is
a stream which is not correctly handled: i.e. it is somehow read
twice.
Maybe if you could provide the full source code and log it could help,
but i really suspect a problem in your code.
Have you tried to work around the problem by transforming the output
of jsr181 in a non stream based source when receiving it and before
processing ? Buti t would just be a workaround imho.
On Tue, Jun 17, 2008 at 1:50 PM, <[EMAIL PROTECTED]> wrote:
> Hi Lars,
>
> I tried to use the MessageUtil.transferInToIn() and
> MessageUtil.transferOutToOut() method but nothing changed. When I switch the
> logging to WARN-level everything crashes, when switched to debug everything
> works fine.
>
> It seems the error only occurs on multi-core cpu's!
>
>
> Here is the error log:
> Somehow the InMsg is empty except for the starting <?xml... ?> Tag
>
> ERROR | pool-flow.seda.servicemix-bean-thread-2 | BeanComponent |
> ervicemix.common.BaseLifeCycle 48 | Error processing exchange InOut[
> id: ID:80.77.211.123-11a7848bddd-2:0
> status: Active
> role: provider
> service: {urn:a}service
> endpoint: endpoint
> in: <?xml version="1.0" encoding="UTF-8"?>
> out: null
> ]
> ...
> at
> org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoint.java:235)
> at
> org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:167)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
>
>
> Regards,
> Jens
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters:
> Lufthansa Systems AS GmbH, Norderstedt
> Registereintragung / Registration:
> Amtsgericht Norderstedt 3688NO
>
> Geschaeftsfuehrung/ Management:
> Bernd Appel
> -----Ursprüngliche Nachricht-----
>
> Von: Lars Heinemann [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 9. Juni 2008 08:56
> An: [email protected]
> Betreff: Re: AW: AW: MessageExchange content empty with 2 beans
>
> Jens,
>
> I don't know if this causes your problems, but please do a test...
>
> Try to use the org.apache.servicemix.jbi.util.MessageUtil class for
> transferring the In and Out messages.
>
> for example:
> instead of
> theDisEx.setInMessage(theExchange.getMessage("in"));
> do
> MessageUtil.transferInToIn(theExchange, theDisEx);
>
> Change this for all transfers.
>
> Another thing which is not so good...
> You just sendSync the exchanges, but you do not check if the result of this
> sending is an error or fault. You just take the out message (which might be
> null in error cases) and use it. This is dangerous.
>
> Think about a construct like this...
>
> if (channel.sendSync(exch))
> {
> if (exch.getStatus() != ExchangeStatus.ERROR)
> {
> ...
> }
> else
> {
> // error
> }
> }
> else
> {
> // can't send
> }
>
>
>
> On Friday 06 June 2008 14:26:06 [EMAIL PROTECTED] wrote:
>> ============= jsr181 to bean1 =================
>>
>> MessageExchange theExchange = JBIContext.getMessageExchange();
>>
>> InOut theDisEx = createInOutExchange(new QName("a", "bean1"));
>>
>> theDisEx.setInMessage(theExchange.getMessage("in"));
>> theDisEx.setProperty("action", "someInfo");
>>
>> sendSync(theDisEx); //send sync to bean 1
>>
>> // do some work with the outMsg from theDisEx
>>
>>
>>
>> ============= bean1 to bean2 back to jsr181 ===============
>>
>> QName theService;
>>
>> if(true) {
>> theService = new QName("a", "bean2");
>> } else {
>> // other endpoints
>> }
>>
>> InOut theInOut = createInOutExchange(theService);
>>
>> // read property "action"
>> // read some fields from the inMsg and send it to the Service
>>
>> theInOut.setInMessage(in); // set inMsg from jsr181 exchange
>> theInOut.setProperty("action", "someInfo");
>>
>> sendSync(theInOut); //send sync to bean 2
>>
>> // set content from bean2 outMsg to content of bean1 outmsg
>> out.setContent(theInOut.getOutMessage().getContent());
>>
>> boolean txSync = exchange.isTransacted() &&
>> Boolean.TRUE.equals(exchange.getProperty(JbiConstants.SEND_SYNC));
>>
>> //send back to jsr181
>> if (txSync) {
>> sendSync(exchange);
>> } else {
>> send(exchange);
>> }
>>
>>
>> =================== bean2 to bean1 ==================
>>
>> theInOut.getInMessage();
>>
>> // unmarshal in msg
>> // do some java processing
>>
>> // marshal object to StringSource
>> // set OutMsg content = new StringSource(myMsgStr)
>>
>> boolean txSync = exchange.isTransacted() &&
>> Boolean.TRUE.equals(exchange.getProperty(JbiConstants.SEND_SYNC));
>>
>> // send back the exchange to bean1
>> if (txSync) {
>> sendSync(theInOut);
>> } else {
>> send(theInOut);
>> }
>>
>>
>> The sendSync method looks like this:
>>
>> protected void sendSync(MessageExchange me) throws MessagingException
>> {
>> long sTime = 0, eTime = 0;
>> if(logger.isDebugEnabled())
>> sTime = System.currentTimeMillis();
>>
>> if (!myDeliveryChannel.sendSync(me)) {
>> throw new MessagingException("SendSync failed");
>> }
>>
>> if(logger.isDebugEnabled()) {
>> eTime = System.currentTimeMillis();
>> logExchange(me);
>> logger.debug("Component called:" +
>>
>> me.getEndpoint().getServiceName() + " duration: " + (eTime - sTime)
>> + "ms");
>> }
>> }
>>
>> The send() method looks similar.
>> And finally the createInOutExchange method:
>>
>> protected InOut createInOutExchange(QName anEndPoint) throws
>> MessagingException {
>> if( myExchangeFactory == null )
>> myExchangeFactory = myDeliveryChannel.createExchangeFactory();
>>
>> InOut theEx = myExchangeFactory.createInOutExchange();
>> if( anEndPoint != null)
>> theEx.setService(anEndPoint);
>> return theEx;
>> }
>>
>> Hopefully this will help...
>>
>>
>>
>>
>> Sitz der Gesellschaft / Corporate Headquarters:
>> Lufthansa Systems AS GmbH, Norderstedt
>> Registereintragung / Registration:
>> Amtsgericht Norderstedt 3688NO
>>
>> Geschaeftsfuehrung/ Management:
>> Bernd Appel
>> -----Ursprüngliche Nachricht-----
>>
>> Von: Lars Heinemann [mailto:[EMAIL PROTECTED]
>> Gesendet: Freitag, 6. Juni 2008 13:29
>> An: [email protected]
>> Betreff: Re: AW: MessageExchange content empty with 2 beans
>>
>> Jens,
>>
>> could you please provide us code snippets where you "route" the exchange
>> from jsr181 to bean1 and from bean1 to bean2 and back the route?
>>
>> Regards,
>> Lars
>>
>> On Friday 06 June 2008 13:13:10 [EMAIL PROTECTED] wrote:
>> > Hi Lars,
>> >
>> > thanks for the quick answer.
>> > We are using
>> > deliverChannel.sendSync(myExchange);
>> > for sending our exchanges.
>> >
>> > We also thought that there is a timing problem, but how can we solve
>> > this?
>> >
>> > We are routing the whole request, because we need all information on the
>> > other bean. And after the bean added some information to the request and
>> > processed some work on the given information, the service will do some
>> > additional work on the data. The first bean acts as an dispatcher and
>> > routes the data to another bean, later on there will be other endpoints
>> > as well to which the data can be routed, depending on which information
>> > are in the data.
>> >
>> > We choose to use a bean-component as a dispatcher and not camel, because
>> > we know the bean-component and thought this will be straight forward and
>> > won't take much time, since we experienced some problems whenever we try
>> > to use a new component.
>> >
>> > @Gerd: in OUR exchanges we use StringSource but since we take the msg
>> > from the jsr181 and route it through, it could be the problem if the
>> > jsr181 uses e.g.: StreamSource.
>> >
>> > Regards,
>> > Jens
>> >
>> >
>> >
>> > Sitz der Gesellschaft / Corporate Headquarters:
>> > Lufthansa Systems AS GmbH, Norderstedt
>> > Registereintragung / Registration:
>> > Amtsgericht Norderstedt 3688NO
>> >
>> > Geschaeftsfuehrung/ Management:
>> > Bernd Appel
>> > -----Ursprüngliche Nachricht-----
>> >
>> > Von: Lars Heinemann [mailto:[EMAIL PROTECTED]
>> > Gesendet: Freitag, 6. Juni 2008 12:44
>> > An: [email protected]
>> > Betreff: Re: MessageExchange content empty with 2 beans
>> >
>> > Jens,
>> >
>> > are you sure, that these exchanges are sent with sendSync in any case?
>> > For me it sounds somehow like a timing problem. When switching to DEBUG
>> > log level, the processing will take much longer time as more outputs are
>> > logged than in the WARN log level.
>> > Another question is, why do you route the whole soap request to other
>> > beans? I mean in your JSR181 SU you could just create a message exchange,
>> > put all needed variables from the soap call into the normalized message
>> > and send it sync to the other beans.
>> >
>> > Regards,
>> > Lars
>> >
>> > On Friday 06 June 2008 12:23:03 [EMAIL PROTECTED] wrote:
>> > > Hi everybody,
>> > >
>> > > We are using a jsr181 service for retrieving soap requests.
>> > > In the service we call the JBIContext.getMessageExchange() method to
>> > > retrieve the actual Exchange.
>> > > Then we send (using sendSync) the InMsg of the Exchange to a bean. The
>> > > bean routes (sendSync) it to another bean.
>> > > When all the work is done and we are back in the jsr181 service we do
>> > > some additional work before we return the response to the sender.
>> > >
>> > > The second bean was added a few days ago. Before that everything worked
>> > > fine. Now with the second been we have a problem:
>> > > The content of every exchange is empty. The InMsg is not null but only
>> > > <?xml ...?> without the actual request data. This starts at the service
>> > > when we log the exchange we got from the
>> > > JBIContext.getMessageExchange() method.
>> > >
>> > > Now comes the tricky part. When we switch the log-level from WARN to
>> > > DEBUG everything works fine! How is this possible?
>> > > Has it something to do with SM-1171 ?
>> > >
>> > > Here are a some information about the usage of the bean-component:
>> > >
>> > > The deployment descriptor for both beans looks similar to this <?xml
>> > > version="1.0" encoding="UTF-8"?> <beans
>> > > xmlns:bean="http://servicemix.apache.org/bean/1.0";
>> > > xmlns:hello="urn:world">
>> > >
>> > > <bean:endpoint service="hello:service" endpoint="endpoint"
>> > > bean="#aBean"/>
>> > >
>> > > <bean id="aBean" class="hello.world.Bean"/> </beans>
>> > >
>> > > The Beans are implementing the MessageExchangeListener, the Context and
>> > > DeliveryChannel are injected by annotations ( @Resource )
>> > >
>> > >
>> > > The flow is like this: (all Exchanges are InOut)
>> > >
>> > > Exchange1 Exchange2 Exchange3 Exchange3 Exchange2
>> > > Exchange1
>> > > In In In Out Out
>> > > Out
>> > > Client => aService => aBean1 => aBean2 => aBean1 =>
>> > > aService => Client
>> > >
>> > > We are using servicemix version 3.2.1
>> > >
>> > > Please Help!
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Sitz der Gesellschaft / Corporate Headquarters:
>> > > Lufthansa Systems AS GmbH, Norderstedt
>> > > Registereintragung / Registration:
>> > > Amtsgericht Norderstedt 3688NO
>> > >
>> > > Geschaeftsfuehrung/ Management:
>> > > Bernd Appel
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
