The Split that Blocked the Camel’s Thread
This is a common pattern: you have a collection of objects — addresses, books, camels, whatever — and you want to farm them out to be processed independently by some handlers. You may or may not care about the results of that processing.
Lately I have been playing around with Apache’s Camel framework, and was trying to implement that exact pattern. In my case, I didn’t care about the results of the processing — I just wanted to fire and forget.
Splitting the collection up and routing the elements to a handler can be done using the
split EIP and a JSON path expression:
And it worked, but I soon discovered I was getting a bunch of thread blocked warnings when my code ran:
WARNING: Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 70654 ms, time limit is 60000
io.vertx.core.VertxException: Thread blocked
split documentation again I realized the calling thread is being blocked until the results return. I suppose the warnings are harmless — the thread will eventually unblock when the handlers complete — but it made debugging the code difficult as the output got littered with these messages and stack traces, and I really didn’t care about the results; there was no further processing being done after the
I searched for a way to make
split not wait for the results, but surprisingly I didn’t find anything. As it turns out, I was approaching the problem from the wrong angle. Rather than focusing on
split, I should have been looking at the calls to the handlers instead, which were made using the
direct component — a synchronous invocation. Once I realized this, a lightbulb went on in my head and the solution to the problem became clear: I needed to call the handlers asynchronously and the magic component to do that is
seda (which stands for staged event-driven architecture):
And the thread blocked warnings went away. While this discovery isn’t exactly earth-shattering, figuring it out did take some effort (the
split documentation didn’t reference
seda even once). Hopefully by sharing this, the next developer in this situation will know what to do and what to avoid.