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.