Hi, We use an object pool (from apache common pool) to cache the open channel to save the connection time. As we don’t have the ChannelPool like the linked norbert, so we don’t have the closeChannelTimeMillis option. For you case it looks the cached the channel was closed when it is still send message. As the camel-netty always checks the channel object before borrowing it from the object pool, it could cause some trouble if you are using the UdpConnectionlessSending[1].
Can you check if you are using the UdpConnectionlessSending in your case. [1]https://github.com/apache/camel/blob/master/components/camel-netty/src/main/java/org/apache/camel/component/netty/NettyProducer.java#L571 -- Willem Jiang Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On October 6, 2015 at 11:44:34 PM, SteveR (srichard...@vonage.com) wrote: > On further investigation, I see that the *closeChannelTimeMillis* option is > not a *netty *option, but rather an option for > com.linkedin.norbert.javacompat.network.NetworkClientConfig > > . > > The Norbert ChannelPool closing channels prematurely > JIRA issue is still in the > unresolved state. > > We are are facing a similar issue in production (with very similar stack > traces for Norbert scenarios 2 and 3, as shown in the JIRA issue) and were > hoping for a resolution to this similar issue. > > Any thoughts on this are appreciated. > > Thanks, SteveR > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-netty-How-to-set-the-netty-closeChannelTimeMillis-option-tp5772342p5772347.html > > Sent from the Camel - Users mailing list archive at Nabble.com. >
