Hi there,
We have a moderately unusual use-case we're having issues implementing.
- Java 8, Camel 2.15.2, Felix w/Camel DSL running in Docker
- UDP server based on camel-netty4 component
- Receiving small (<100 bytes), stateless messages
- Sending small, per-message responses
The problem is performance-related: Due to netty4's standard threading
model, there's one worker thread per channel to maintain order (UDP
listening port, in this case; somewhat known issue), despite settings such
as workerCount. In testing, this has proven too slow with given hardware, so
we'd like to parallelize processing since request/response order isn't
critical.
To attempt this, we changed our DSL to attempt the asyc request/reply
pattern, like so (note "sync=true", as we send responses):
from("<netty-uri>?sync=true")
.process(<processors>)
...to:
from("<netty-uri>?sync=true")
.threads(10)
.process(<processors>)
With the threads() call in place, however, responses don't appear to be
getting back to the clients.
We've debugged the async callback through the Consumer and at least that's
happening but we're not sure what's going on beyond there. The destination
address (an ephemeral port on the remote client) seems to make it through in
metadata. Sniffing around on Wireshark might help, but things are
complicated in that department (Felix running in Docker, Docker running in a
Ubuntu VM, ...).
Should this work, either with this thread pool or something like SEDA
endpoints in the middle? By going asynchronous, netty4 is no longer getting
direct responses, so does sync=true or disconnectOnNoReply have any bearing?
Any better ideas how to accomplish this?
Thanks for your time, in advance.
--
View this message in context:
http://camel.465427.n5.nabble.com/Multi-threaded-UDP-server-with-netty4-tp5774901.html
Sent from the Camel - Users mailing list archive at Nabble.com.
