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?
Regards,
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
<bjorn.elling...@baymarkets.com> 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.
