camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjørn Ellingsen <>
Subject Re: Lost messages when streaming with Jetty
Date Tue, 14 Jun 2016 20:34:41 GMT
Thanks for the reply,

in this case the sender has no interest in any replies, that's exactly 
why I changed to InOnly in the first place. A response with content 
length zero is perfect, only the HTTP status code is relevant for the 
sender. It was perhaps misleading to add a return of anything from the 
bean in my example. The sender wants to deliver a message, doesn't care 
for a response (body), and shouldn't block any longer than necessary 
(just until the message is delivered to the vm endpoint, I guess). Is 
there a way to accomplish this when using a HTTP based endpoint - Jetty 
in this case?

Bjørn E.

On 14. juni 2016 17:23, Claus Ibsen wrote:
> If you want jetty to return the response from the VM endpoint then you
> need to use InOut pattern so it wait for the reply message to be
> ready. Otherwise you have concurrent threads that .. depending on
> timing .. will set the reply either before or after jetty writes the
> response.
> If you want to fork the message to vm and let it route independent on
> jetty, then consider using wire tap eip
> from jetty
>    wire tap vm foo
>    set body OK
>     // jetty returns OK
> from vm foo
>     .. // route independet
> On Tue, Jun 14, 2016 at 1:44 PM, Bjørn Ellingsen
> <> wrote:
>> Hi, I get sporadic cases of no body when having a client sending small JSON
>> messages over http, and a jetty endpoint receiving them, and a short route
>> with a vm endpoint and a bean. Stream-caching is enabled. The issue only
>> appears when MEP is InOnly. A simple test case to reproduce the issue is
>> attached, you might have to adjust (increase) the message count if test
>> executes without failure.
>> Enabling trace logging on org.apache.camel, there is only one log statement
>> I noticed to differ when message came through vs. was lost:
>> 2016-06-14 12:50:49.441 [TRACE] [MethodInfo] []: Parameter #0 evaluated as:
>> {"key1":"value1","key2":"value2","key3":"value3","key4":"value4","key5":"value5"}
>> type:
>> vs.:
>> 2016-06-14 12:50:49.547 [TRACE] [MethodInfo] []: Parameter #0 evaluated as:
>> type:
>> The number of lost messages - or empty bodied messages - when running this
>> test case is in the range 5-50 (out of 800). I have avoided the issue for
>> now by converting the body from stream to string, but I would really like to
>> know if I'm using the API wrong or if there is a bug hidden somewhere. Any
>> help appreciated.
>> Versions etc:
>> Camel: 2.17.1
>> JDK: 1.8.0_77
>> Jetty: 9.2.15 (also tried 9.1.6)
>> OS: Fedora + RHEL
>> Same result if using other client than camel-http
>> Regards,
>> Bjørn E.

View raw message