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 f
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 fo
Hi, enabling MDC to tie output together, I can see some discrepancies
between the OK and the NOT-OK cases (these are probably present when
turning on trace logging as well, but are harder to catch due to the
vast amount of log statements):
OK scenario:
2016-06-14 15:27:01.029 [INFO] [CamelStr
Hi,
Yeah probably something between the VM endpoint and the bean caused this.
I extend CamelBlueprintTestSupport but works for normal CamelTestSupport as
well. Hopefully the debug log will reveal what could be going wrong in
between. See below for adding the debug methods:
public class yourtestc
Thanks for the quick reply, adding a log step to the route right after
message is received by the jetty component confirms that all exchanges
have a complete body at that point. I suspect the issue is related to
the transition from delivery to vm:test and consumption by the bean from
the same e
Hello,
I am not able to test this at the moment but what happens if you change the
first "from" to from("jetty:" + URI).log("${body} and ${headers}".to("")
In the case of the empty messages, does the log statement also show that
the body being empty?
You can also include debug level logs in your
