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.

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 (srichardson@vonage.com) wrote:
On further investigation, I see that the *closeChannelTimeMillis* option is
not a *netty *option, but rather an option for


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.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 5 | next ›
Discussion Overview
groupusers @
postedOct 6, '15 at 2:54p
activeOct 12, '15 at 3:25a

2 users in discussion

SteveR: 3 posts Willem Jiang: 2 posts



site design / logo © 2021 Grokbase