You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Andrew Chandler <an...@riftware.com> on 2010/04/08 19:14:53 UTC
Mina blows up
Hi there folks - hoping you can help me from gaining a permanent dent in
my end from hitting the wall. We are using Camel for many things but
we have setup a dedicate route to a simple standalone process - both
ends set up a send and a receive route (different ports) - The route
works until it doesn't. We are putting in simple text messages in
the form of "9,10.9.9.9" That is an entire message so there
shouldn't be any reason for the error we are getting except that we are
multithreaded on the both ends. We are using camel 2.2, and mina-core
1.1.7 , Even if you don't know how to guide me to fixing the problem
if anybody is able to succesffuly decode the blasted hex dump into
meaningful text so that I can understand how the "line is too long" is
occuring it would be wonderful.
routes are setup as follows: First the simple standalone process sets
up route to send responses when work is done to the main process:
from("direct:rcv").to(
"mina:tcp://"
+
responder.this.pingResponseHost
+ ":"
+
responder.this.pingResponsePort
+ "?textline=true&sync=true");
and a snippet from the more comlicated route
getFormatOutgoingPingProcessor()).to(
"mina:tcp://" + daemonAddress +
"?textline=true&sync=true");
The following message was generated on the Main process sending to
standalone process side. My assumption below is that we're somehow
overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
there were lots of those messages being sent quickly but still)
26931 [Camel thread 23: Threads] ERROR
camel.processor.DefaultErrorHandler - Failed delivery for
exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
org.apache.mina.common.BufferDataException: Line is too long: 1472
(Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
failure processor:
Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
$SimpleExceptionProcessor@1d82752b],
Channel[Stop]]
Re: Mina blows up
Posted by Andrew Chandler <an...@riftware.com>.
Well I fixed it I think - our routes weren't expecting to return a
response and it ultimately seems to have turned out to the default of
sync=true , not sure why the error message in question was what it was
but essentially when work after mina was done and transitioned through a
splitter etc apparenlty the messages coming out of the splitter got
returned as a response to the mina queue which choked on it because
there were non - serializable items and actually fairly large items too.
On Thu, 2010-04-08 at 14:14 -0500, Andrew Chandler wrote:
> Is there anything wrong with this definition:
> from("direct:rcv").to("mina:tcp://" + pingResponseHost +":" +
> pingResponsePort + "?timeout=300000&transferExchange=false"/*+
> "?textline=true"*/);
>
> My expectation is that the textline is ignored (commented out) and
> that I have set a tcp object serialized connection outbound with a
> timeout of 300 seconds. I can tell you that I'm seeing this error
> within 30 seconds :
>
>
>
>
>
> ERROR Failed delivery for exchangeId:
> 128c966e-499b-4383-82b1-bf6badd9d504. Exhausted after delivery
> attempt: 1 caught: org.apache.camel.CamelExchangeException: No
> response received from remote server:
> mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
> Exchange[Message: 3,439]
> org.apache.camel.CamelExchangeException: No response received from
> remote server:
> mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
> Exchange[Message: 3,439]
>
>
> On Thu, 2010-04-08 at 13:52 -0500, Andrew Chandler wrote:
>
> > Ok further weirdness - since I'm using tcp and I don't really care
> > if my objects go as text I just wanted a lightweight socket protocol
> > I took the textline bit out of my uri's (should be serialized
> > objects now ) So in watching it worked for a couple of seconds and
> > then it blew up, however when it blew up it was because it was
> > trying tserialize some object that shouldn't have been present in
> > the message body presented to mina (might have been in a header).
> > My understanding of the doc was that only the body should ever get
> > serialized by default (could have been happening with textline too
> > for all I know). So I added the transferExchange=false
> > explicitly and am about to test that. I'll let you know what I
> > find.
> >
> >
> > On Thu, 2010-04-08 at 13:05 -0500, Andrew Chandler wrote:
> >
> > > Ok I'll look at that but what puzzles me is if each message is
> > > sent and is only ever an int,IPADDRESS structure how could it
> > > exceed 1024? Or is the buffer length really ALL messages that
> > > are pending for work?
> > >
> > >
> > >
> > > On Thu, 2010-04-08 at 19:59 +0200, Claus Ibsen wrote:
> > >
> > > > Hi
> > > >
> > > > Have you looked at the encorder/decoder max length options.
> > > > http://camel.apache.org/mina.html
> > > >
> > > > Could be that Mina has a default of one of them at 1024.
> > > >
> > > >
> > > >
> > > > On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> > > > > Hi there folks - hoping you can help me from gaining a permanent dent in
> > > > > my end from hitting the wall. We are using Camel for many things but
> > > > > we have setup a dedicate route to a simple standalone process - both
> > > > > ends set up a send and a receive route (different ports) - The route
> > > > > works until it doesn't. We are putting in simple text messages in
> > > > > the form of "9,10.9.9.9" That is an entire message so there
> > > > > shouldn't be any reason for the error we are getting except that we are
> > > > > multithreaded on the both ends. We are using camel 2.2, and mina-core
> > > > > 1.1.7 , Even if you don't know how to guide me to fixing the problem
> > > > > if anybody is able to succesffuly decode the blasted hex dump into
> > > > > meaningful text so that I can understand how the "line is too long" is
> > > > > occuring it would be wonderful.
> > > > >
> > > > >
> > > > > routes are setup as follows: First the simple standalone process sets
> > > > > up route to send responses when work is done to the main process:
> > > > > from("direct:rcv").to(
> > > > > "mina:tcp://"
> > > > > +
> > > > > responder.this.pingResponseHost
> > > > > + ":"
> > > > > +
> > > > > responder.this.pingResponsePort
> > > > > + "?textline=true&sync=true");
> > > > >
> > > > >
> > > > > and a snippet from the more comlicated route
> > > > > getFormatOutgoingPingProcessor()).to(
> > > > > "mina:tcp://" + daemonAddress +
> > > > > "?textline=true&sync=true");
> > > > >
> > > > >
> > > > > The following message was generated on the Main process sending to
> > > > > standalone process side. My assumption below is that we're somehow
> > > > > overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
> > > > > there were lots of those messages being sent quickly but still)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 26931 [Camel thread 23: Threads] ERROR
> > > > > camel.processor.DefaultErrorHandler - Failed delivery for
> > > > > exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
> > > > > delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
> > > > > Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
> > > > > Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
> > > > > org.apache.mina.common.BufferDataException: Line is too long: 1472
> > > > > (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
> > > > > 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > > > > 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
> > > > > 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > > > > 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
> > > > > 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
> > > > > 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
> > > > > 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
> > > > > 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
> > > > > 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
> > > > > 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
> > > > > 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
> > > > > 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
> > > > > 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
> > > > > 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
> > > > > 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
> > > > > 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
> > > > > 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
> > > > > 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
> > > > > failure processor:
> > > > > Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
> > > > > $SimpleExceptionProcessor@1d82752b],
> > > > > Channel[Stop]]
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Mina blows up
Posted by Andrew Chandler <an...@riftware.com>.
Thanks Clause - in this case that wasn't it - line wrapping made it less
obvious but you can see the second ? was in a
commented out section /* */ I had switched to object serialization to
try and track the problem which ultimately helped.
by switching to object serialization it started complaining about an
unserializable object that wasn't supposed to be going
through this section of the route. FINALLY figured out it was the
sync=true default that was killing us - our routes don't
expect to have responses sent back so since we didn't explicitly provide
a response it somehow assumed the first thing in the route that
generated a message was the response and was sending back very large
objects. While in textline mode it was less obvious because everything
being sent back had a "toString"
On Fri, 2010-04-09 at 05:56 +0200, Claus Ibsen wrote:
> You uri is wrong. You can only have 1 ? in the ur. It should be &textline=true.
>
>
> On Thu, Apr 8, 2010 at 9:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> > Is there anything wrong with this definition:
> > from("direct:rcv").to("mina:tcp://" + pingResponseHost +":" +
> > pingResponsePort + "?timeout=300000&transferExchange=false"/*+
> > "?textline=true"*/);
> >
> > My expectation is that the textline is ignored (commented out) and that
> > I have set a tcp object serialized connection outbound with a timeout of
> > 300 seconds. I can tell you that I'm seeing this error within 30
> > seconds :
> >
> >
> >
> >
> >
> > ERROR Failed delivery for exchangeId:
> > 128c966e-499b-4383-82b1-bf6badd9d504. Exhausted after delivery attempt:
> > 1 caught: org.apache.camel.CamelExchangeException: No response received
> > from remote server:
> > mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
> > Exchange[Message: 3,439]
> > org.apache.camel.CamelExchangeException: No response received from
> > remote server:
> > mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
> > Exchange[Message: 3,439]
> >
> >
> > On Thu, 2010-04-08 at 13:52 -0500, Andrew Chandler wrote:
> >
> >> Ok further weirdness - since I'm using tcp and I don't really care if
> >> my objects go as text I just wanted a lightweight socket protocol I
> >> took the textline bit out of my uri's (should be serialized objects
> >> now ) So in watching it worked for a couple of seconds and then it
> >> blew up, however when it blew up it was because it was trying
> >> tserialize some object that shouldn't have been present in the message
> >> body presented to mina (might have been in a header). My
> >> understanding of the doc was that only the body should ever get
> >> serialized by default (could have been happening with textline too for
> >> all I know). So I added the transferExchange=false explicitly and
> >> am about to test that. I'll let you know what I find.
> >>
> >>
> >> On Thu, 2010-04-08 at 13:05 -0500, Andrew Chandler wrote:
> >>
> >> > Ok I'll look at that but what puzzles me is if each message is sent
> >> > and is only ever an int,IPADDRESS structure how could it exceed
> >> > 1024? Or is the buffer length really ALL messages that are pending
> >> > for work?
> >> >
> >> >
> >> >
> >> > On Thu, 2010-04-08 at 19:59 +0200, Claus Ibsen wrote:
> >> >
> >> > > Hi
> >> > >
> >> > > Have you looked at the encorder/decoder max length options.
> >> > > http://camel.apache.org/mina.html
> >> > >
> >> > > Could be that Mina has a default of one of them at 1024.
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> >> > > > Hi there folks - hoping you can help me from gaining a permanent dent in
> >> > > > my end from hitting the wall. We are using Camel for many things but
> >> > > > we have setup a dedicate route to a simple standalone process - both
> >> > > > ends set up a send and a receive route (different ports) - The route
> >> > > > works until it doesn't. We are putting in simple text messages in
> >> > > > the form of "9,10.9.9.9" That is an entire message so there
> >> > > > shouldn't be any reason for the error we are getting except that we are
> >> > > > multithreaded on the both ends. We are using camel 2.2, and mina-core
> >> > > > 1.1.7 , Even if you don't know how to guide me to fixing the problem
> >> > > > if anybody is able to succesffuly decode the blasted hex dump into
> >> > > > meaningful text so that I can understand how the "line is too long" is
> >> > > > occuring it would be wonderful.
> >> > > >
> >> > > >
> >> > > > routes are setup as follows: First the simple standalone process sets
> >> > > > up route to send responses when work is done to the main process:
> >> > > > from("direct:rcv").to(
> >> > > > "mina:tcp://"
> >> > > > +
> >> > > > responder.this.pingResponseHost
> >> > > > + ":"
> >> > > > +
> >> > > > responder.this.pingResponsePort
> >> > > > + "?textline=true&sync=true");
> >> > > >
> >> > > >
> >> > > > and a snippet from the more comlicated route
> >> > > > getFormatOutgoingPingProcessor()).to(
> >> > > > "mina:tcp://" + daemonAddress +
> >> > > > "?textline=true&sync=true");
> >> > > >
> >> > > >
> >> > > > The following message was generated on the Main process sending to
> >> > > > standalone process side. My assumption below is that we're somehow
> >> > > > overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
> >> > > > there were lots of those messages being sent quickly but still)
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > 26931 [Camel thread 23: Threads] ERROR
> >> > > > camel.processor.DefaultErrorHandler - Failed delivery for
> >> > > > exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
> >> > > > delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
> >> > > > Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
> >> > > > Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
> >> > > > org.apache.mina.common.BufferDataException: Line is too long: 1472
> >> > > > (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
> >> > > > 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> >> > > > 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
> >> > > > 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> >> > > > 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
> >> > > > 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
> >> > > > 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
> >> > > > 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
> >> > > > 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
> >> > > > 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
> >> > > > 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
> >> > > > 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
> >> > > > 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
> >> > > > 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
> >> > > > 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
> >> > > > 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
> >> > > > 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
> >> > > > 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
> >> > > > 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
> >> > > > failure processor:
> >> > > > Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
> >> > > > $SimpleExceptionProcessor@1d82752b],
> >> > > > Channel[Stop]]
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
> >
>
>
>
Re: Mina blows up
Posted by Claus Ibsen <cl...@gmail.com>.
You uri is wrong. You can only have 1 ? in the ur. It should be &textline=true.
On Thu, Apr 8, 2010 at 9:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> Is there anything wrong with this definition:
> from("direct:rcv").to("mina:tcp://" + pingResponseHost +":" +
> pingResponsePort + "?timeout=300000&transferExchange=false"/*+
> "?textline=true"*/);
>
> My expectation is that the textline is ignored (commented out) and that
> I have set a tcp object serialized connection outbound with a timeout of
> 300 seconds. I can tell you that I'm seeing this error within 30
> seconds :
>
>
>
>
>
> ERROR Failed delivery for exchangeId:
> 128c966e-499b-4383-82b1-bf6badd9d504. Exhausted after delivery attempt:
> 1 caught: org.apache.camel.CamelExchangeException: No response received
> from remote server:
> mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
> Exchange[Message: 3,439]
> org.apache.camel.CamelExchangeException: No response received from
> remote server:
> mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
> Exchange[Message: 3,439]
>
>
> On Thu, 2010-04-08 at 13:52 -0500, Andrew Chandler wrote:
>
>> Ok further weirdness - since I'm using tcp and I don't really care if
>> my objects go as text I just wanted a lightweight socket protocol I
>> took the textline bit out of my uri's (should be serialized objects
>> now ) So in watching it worked for a couple of seconds and then it
>> blew up, however when it blew up it was because it was trying
>> tserialize some object that shouldn't have been present in the message
>> body presented to mina (might have been in a header). My
>> understanding of the doc was that only the body should ever get
>> serialized by default (could have been happening with textline too for
>> all I know). So I added the transferExchange=false explicitly and
>> am about to test that. I'll let you know what I find.
>>
>>
>> On Thu, 2010-04-08 at 13:05 -0500, Andrew Chandler wrote:
>>
>> > Ok I'll look at that but what puzzles me is if each message is sent
>> > and is only ever an int,IPADDRESS structure how could it exceed
>> > 1024? Or is the buffer length really ALL messages that are pending
>> > for work?
>> >
>> >
>> >
>> > On Thu, 2010-04-08 at 19:59 +0200, Claus Ibsen wrote:
>> >
>> > > Hi
>> > >
>> > > Have you looked at the encorder/decoder max length options.
>> > > http://camel.apache.org/mina.html
>> > >
>> > > Could be that Mina has a default of one of them at 1024.
>> > >
>> > >
>> > >
>> > > On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
>> > > > Hi there folks - hoping you can help me from gaining a permanent dent in
>> > > > my end from hitting the wall. We are using Camel for many things but
>> > > > we have setup a dedicate route to a simple standalone process - both
>> > > > ends set up a send and a receive route (different ports) - The route
>> > > > works until it doesn't. We are putting in simple text messages in
>> > > > the form of "9,10.9.9.9" That is an entire message so there
>> > > > shouldn't be any reason for the error we are getting except that we are
>> > > > multithreaded on the both ends. We are using camel 2.2, and mina-core
>> > > > 1.1.7 , Even if you don't know how to guide me to fixing the problem
>> > > > if anybody is able to succesffuly decode the blasted hex dump into
>> > > > meaningful text so that I can understand how the "line is too long" is
>> > > > occuring it would be wonderful.
>> > > >
>> > > >
>> > > > routes are setup as follows: First the simple standalone process sets
>> > > > up route to send responses when work is done to the main process:
>> > > > from("direct:rcv").to(
>> > > > "mina:tcp://"
>> > > > +
>> > > > responder.this.pingResponseHost
>> > > > + ":"
>> > > > +
>> > > > responder.this.pingResponsePort
>> > > > + "?textline=true&sync=true");
>> > > >
>> > > >
>> > > > and a snippet from the more comlicated route
>> > > > getFormatOutgoingPingProcessor()).to(
>> > > > "mina:tcp://" + daemonAddress +
>> > > > "?textline=true&sync=true");
>> > > >
>> > > >
>> > > > The following message was generated on the Main process sending to
>> > > > standalone process side. My assumption below is that we're somehow
>> > > > overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
>> > > > there were lots of those messages being sent quickly but still)
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > 26931 [Camel thread 23: Threads] ERROR
>> > > > camel.processor.DefaultErrorHandler - Failed delivery for
>> > > > exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
>> > > > delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
>> > > > Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
>> > > > Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
>> > > > org.apache.mina.common.BufferDataException: Line is too long: 1472
>> > > > (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
>> > > > 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
>> > > > 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
>> > > > 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
>> > > > 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
>> > > > 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
>> > > > 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
>> > > > 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
>> > > > 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
>> > > > 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
>> > > > 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
>> > > > 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
>> > > > 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
>> > > > 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
>> > > > 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
>> > > > 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
>> > > > 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
>> > > > 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
>> > > > 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
>> > > > failure processor:
>> > > > Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
>> > > > $SimpleExceptionProcessor@1d82752b],
>> > > > Channel[Stop]]
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Mina blows up
Posted by Andrew Chandler <an...@riftware.com>.
Is there anything wrong with this definition:
from("direct:rcv").to("mina:tcp://" + pingResponseHost +":" +
pingResponsePort + "?timeout=300000&transferExchange=false"/*+
"?textline=true"*/);
My expectation is that the textline is ignored (commented out) and that
I have set a tcp object serialized connection outbound with a timeout of
300 seconds. I can tell you that I'm seeing this error within 30
seconds :
ERROR Failed delivery for exchangeId:
128c966e-499b-4383-82b1-bf6badd9d504. Exhausted after delivery attempt:
1 caught: org.apache.camel.CamelExchangeException: No response received
from remote server:
mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
Exchange[Message: 3,439]
org.apache.camel.CamelExchangeException: No response received from
remote server:
mina://tcp://localhost:5556?timeout=300000&transferExchange=false.
Exchange[Message: 3,439]
On Thu, 2010-04-08 at 13:52 -0500, Andrew Chandler wrote:
> Ok further weirdness - since I'm using tcp and I don't really care if
> my objects go as text I just wanted a lightweight socket protocol I
> took the textline bit out of my uri's (should be serialized objects
> now ) So in watching it worked for a couple of seconds and then it
> blew up, however when it blew up it was because it was trying
> tserialize some object that shouldn't have been present in the message
> body presented to mina (might have been in a header). My
> understanding of the doc was that only the body should ever get
> serialized by default (could have been happening with textline too for
> all I know). So I added the transferExchange=false explicitly and
> am about to test that. I'll let you know what I find.
>
>
> On Thu, 2010-04-08 at 13:05 -0500, Andrew Chandler wrote:
>
> > Ok I'll look at that but what puzzles me is if each message is sent
> > and is only ever an int,IPADDRESS structure how could it exceed
> > 1024? Or is the buffer length really ALL messages that are pending
> > for work?
> >
> >
> >
> > On Thu, 2010-04-08 at 19:59 +0200, Claus Ibsen wrote:
> >
> > > Hi
> > >
> > > Have you looked at the encorder/decoder max length options.
> > > http://camel.apache.org/mina.html
> > >
> > > Could be that Mina has a default of one of them at 1024.
> > >
> > >
> > >
> > > On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> > > > Hi there folks - hoping you can help me from gaining a permanent dent in
> > > > my end from hitting the wall. We are using Camel for many things but
> > > > we have setup a dedicate route to a simple standalone process - both
> > > > ends set up a send and a receive route (different ports) - The route
> > > > works until it doesn't. We are putting in simple text messages in
> > > > the form of "9,10.9.9.9" That is an entire message so there
> > > > shouldn't be any reason for the error we are getting except that we are
> > > > multithreaded on the both ends. We are using camel 2.2, and mina-core
> > > > 1.1.7 , Even if you don't know how to guide me to fixing the problem
> > > > if anybody is able to succesffuly decode the blasted hex dump into
> > > > meaningful text so that I can understand how the "line is too long" is
> > > > occuring it would be wonderful.
> > > >
> > > >
> > > > routes are setup as follows: First the simple standalone process sets
> > > > up route to send responses when work is done to the main process:
> > > > from("direct:rcv").to(
> > > > "mina:tcp://"
> > > > +
> > > > responder.this.pingResponseHost
> > > > + ":"
> > > > +
> > > > responder.this.pingResponsePort
> > > > + "?textline=true&sync=true");
> > > >
> > > >
> > > > and a snippet from the more comlicated route
> > > > getFormatOutgoingPingProcessor()).to(
> > > > "mina:tcp://" + daemonAddress +
> > > > "?textline=true&sync=true");
> > > >
> > > >
> > > > The following message was generated on the Main process sending to
> > > > standalone process side. My assumption below is that we're somehow
> > > > overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
> > > > there were lots of those messages being sent quickly but still)
> > > >
> > > >
> > > >
> > > >
> > > > 26931 [Camel thread 23: Threads] ERROR
> > > > camel.processor.DefaultErrorHandler - Failed delivery for
> > > > exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
> > > > delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
> > > > Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
> > > > Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
> > > > org.apache.mina.common.BufferDataException: Line is too long: 1472
> > > > (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
> > > > 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > > > 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
> > > > 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > > > 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
> > > > 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
> > > > 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
> > > > 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
> > > > 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
> > > > 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
> > > > 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
> > > > 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
> > > > 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
> > > > 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
> > > > 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
> > > > 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
> > > > 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
> > > > 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
> > > > 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
> > > > failure processor:
> > > > Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
> > > > $SimpleExceptionProcessor@1d82752b],
> > > > Channel[Stop]]
> > > >
> > >
> > >
> > >
> >
> >
>
>
Re: Mina blows up
Posted by Andrew Chandler <an...@riftware.com>.
Ok further weirdness - since I'm using tcp and I don't really care if my
objects go as text I just wanted a lightweight socket protocol I took
the textline bit out of my uri's (should be serialized objects now )
So in watching it worked for a couple of seconds and then it blew up,
however when it blew up it was because it was trying tserialize some
object that shouldn't have been present in the message body presented to
mina (might have been in a header). My understanding of the doc was
that only the body should ever get serialized by default (could have
been happening with textline too for all I know). So I added the
transferExchange=false explicitly and am about to test that. I'll let
you know what I find.
On Thu, 2010-04-08 at 13:05 -0500, Andrew Chandler wrote:
> Ok I'll look at that but what puzzles me is if each message is sent
> and is only ever an int,IPADDRESS structure how could it exceed
> 1024? Or is the buffer length really ALL messages that are pending
> for work?
>
>
>
> On Thu, 2010-04-08 at 19:59 +0200, Claus Ibsen wrote:
>
> > Hi
> >
> > Have you looked at the encorder/decoder max length options.
> > http://camel.apache.org/mina.html
> >
> > Could be that Mina has a default of one of them at 1024.
> >
> >
> >
> > On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> > > Hi there folks - hoping you can help me from gaining a permanent dent in
> > > my end from hitting the wall. We are using Camel for many things but
> > > we have setup a dedicate route to a simple standalone process - both
> > > ends set up a send and a receive route (different ports) - The route
> > > works until it doesn't. We are putting in simple text messages in
> > > the form of "9,10.9.9.9" That is an entire message so there
> > > shouldn't be any reason for the error we are getting except that we are
> > > multithreaded on the both ends. We are using camel 2.2, and mina-core
> > > 1.1.7 , Even if you don't know how to guide me to fixing the problem
> > > if anybody is able to succesffuly decode the blasted hex dump into
> > > meaningful text so that I can understand how the "line is too long" is
> > > occuring it would be wonderful.
> > >
> > >
> > > routes are setup as follows: First the simple standalone process sets
> > > up route to send responses when work is done to the main process:
> > > from("direct:rcv").to(
> > > "mina:tcp://"
> > > +
> > > responder.this.pingResponseHost
> > > + ":"
> > > +
> > > responder.this.pingResponsePort
> > > + "?textline=true&sync=true");
> > >
> > >
> > > and a snippet from the more comlicated route
> > > getFormatOutgoingPingProcessor()).to(
> > > "mina:tcp://" + daemonAddress +
> > > "?textline=true&sync=true");
> > >
> > >
> > > The following message was generated on the Main process sending to
> > > standalone process side. My assumption below is that we're somehow
> > > overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
> > > there were lots of those messages being sent quickly but still)
> > >
> > >
> > >
> > >
> > > 26931 [Camel thread 23: Threads] ERROR
> > > camel.processor.DefaultErrorHandler - Failed delivery for
> > > exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
> > > delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
> > > Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
> > > Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
> > > org.apache.mina.common.BufferDataException: Line is too long: 1472
> > > (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
> > > 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > > 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
> > > 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > > 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
> > > 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
> > > 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
> > > 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
> > > 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
> > > 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
> > > 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
> > > 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
> > > 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
> > > 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
> > > 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
> > > 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
> > > 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
> > > 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
> > > 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
> > > failure processor:
> > > Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
> > > $SimpleExceptionProcessor@1d82752b],
> > > Channel[Stop]]
> > >
> >
> >
> >
>
>
Re: Mina blows up
Posted by Andrew Chandler <an...@riftware.com>.
Ok I'll look at that but what puzzles me is if each message is sent and
is only ever an int,IPADDRESS structure how could it exceed 1024? Or
is the buffer length really ALL messages that are pending for work?
On Thu, 2010-04-08 at 19:59 +0200, Claus Ibsen wrote:
> Hi
>
> Have you looked at the encorder/decoder max length options.
> http://camel.apache.org/mina.html
>
> Could be that Mina has a default of one of them at 1024.
>
>
>
> On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> > Hi there folks - hoping you can help me from gaining a permanent dent in
> > my end from hitting the wall. We are using Camel for many things but
> > we have setup a dedicate route to a simple standalone process - both
> > ends set up a send and a receive route (different ports) - The route
> > works until it doesn't. We are putting in simple text messages in
> > the form of "9,10.9.9.9" That is an entire message so there
> > shouldn't be any reason for the error we are getting except that we are
> > multithreaded on the both ends. We are using camel 2.2, and mina-core
> > 1.1.7 , Even if you don't know how to guide me to fixing the problem
> > if anybody is able to succesffuly decode the blasted hex dump into
> > meaningful text so that I can understand how the "line is too long" is
> > occuring it would be wonderful.
> >
> >
> > routes are setup as follows: First the simple standalone process sets
> > up route to send responses when work is done to the main process:
> > from("direct:rcv").to(
> > "mina:tcp://"
> > +
> > responder.this.pingResponseHost
> > + ":"
> > +
> > responder.this.pingResponsePort
> > + "?textline=true&sync=true");
> >
> >
> > and a snippet from the more comlicated route
> > getFormatOutgoingPingProcessor()).to(
> > "mina:tcp://" + daemonAddress +
> > "?textline=true&sync=true");
> >
> >
> > The following message was generated on the Main process sending to
> > standalone process side. My assumption below is that we're somehow
> > overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
> > there were lots of those messages being sent quickly but still)
> >
> >
> >
> >
> > 26931 [Camel thread 23: Threads] ERROR
> > camel.processor.DefaultErrorHandler - Failed delivery for
> > exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
> > delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
> > Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
> > Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
> > org.apache.mina.common.BufferDataException: Line is too long: 1472
> > (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
> > 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
> > 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> > 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
> > 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
> > 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
> > 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
> > 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
> > 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
> > 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
> > 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
> > 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
> > 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
> > 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
> > 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
> > 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
> > 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
> > 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
> > failure processor:
> > Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
> > $SimpleExceptionProcessor@1d82752b],
> > Channel[Stop]]
> >
>
>
>
Re: Mina blows up
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Have you looked at the encorder/decoder max length options.
http://camel.apache.org/mina.html
Could be that Mina has a default of one of them at 1024.
On Thu, Apr 8, 2010 at 7:14 PM, Andrew Chandler <an...@riftware.com> wrote:
> Hi there folks - hoping you can help me from gaining a permanent dent in
> my end from hitting the wall. We are using Camel for many things but
> we have setup a dedicate route to a simple standalone process - both
> ends set up a send and a receive route (different ports) - The route
> works until it doesn't. We are putting in simple text messages in
> the form of "9,10.9.9.9" That is an entire message so there
> shouldn't be any reason for the error we are getting except that we are
> multithreaded on the both ends. We are using camel 2.2, and mina-core
> 1.1.7 , Even if you don't know how to guide me to fixing the problem
> if anybody is able to succesffuly decode the blasted hex dump into
> meaningful text so that I can understand how the "line is too long" is
> occuring it would be wonderful.
>
>
> routes are setup as follows: First the simple standalone process sets
> up route to send responses when work is done to the main process:
> from("direct:rcv").to(
> "mina:tcp://"
> +
> responder.this.pingResponseHost
> + ":"
> +
> responder.this.pingResponsePort
> + "?textline=true&sync=true");
>
>
> and a snippet from the more comlicated route
> getFormatOutgoingPingProcessor()).to(
> "mina:tcp://" + daemonAddress +
> "?textline=true&sync=true");
>
>
> The following message was generated on the Main process sending to
> standalone process side. My assumption below is that we're somehow
> overrunnign a buffer with a Message = 10.3.1.12,13 ??????? (Mind you
> there were lots of those messages being sent quickly but still)
>
>
>
>
> 26931 [Camel thread 23: Threads] ERROR
> camel.processor.DefaultErrorHandler - Failed delivery for
> exchangeId: 5081d54b-5824-4598-94cb-f202559e6e84. Exhausted after
> delivery attempt: 1 caught: org.apache.camel.CamelExchangeException:
> Response Handler had an exception. Exchange[Message: 10.3.1.12,13].
> Caused by: [org.apache.mina.filter.codec.ProtocolDecoderException -
> org.apache.mina.common.BufferDataException: Line is too long: 1472
> (Hexdump: 34 20 36 35 20 36 44 20 35 33 20 36 35 20 37 32 20 37 36 20 36
> 39 20 36 33 20 36 35 20 37 33 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> 33 20 37 39 20 37 33 20 37 34 20 36 35 20 36 44 20 35 35 20 37 30 20 35
> 34 20 36 39 20 36 44 20 36 35 20 33 44 20 33 30 20 32 43 20 32 30 20 37
> 34 20 37 39 20 37 30 20 36 35 20 33 44 20 36 45 20 37 35 20 36 43 20 36
> 43 20 35 44 20 32 43 20 32 30 20 36 45 20 36 33 20 36 44 20 35 34 20 36
> 31 20 37 33 20 36 42 20 34 39 20 36 34 20 33 44 20 36 32 20 33 38 20 36
> 34 20 33 32 20 33 30 20 33 35 20 36 35 20 33 32 20 32 44 20 36 32 20 33
> 39 20 33 31 20 36 31 20 32 44 20 33 34 20 36 34 20 33 36 20 33 31 20 32
> 44 20 33 38 20 33 39 20 33 34 20 33 33 20 32 44 20 33 33 20 33 33 20 33
> 37 20 33 35 20 36 32 20 33 32 20 33 32 20 36 31 20 36 32 20 33 35 20 33
> 30 20 33 33 20 32 45 20 33 31 20 33 31 20 32 43 20 32 30 20 36 39 20 36
> 33 20 36 44 20 37 30 20 35 30 20 36 39 20 36 45 20 36 37 20 35 33 20 37
> 34 20 36 31 20 37 34 20 37 35 20 37 33 20 34 36 20 36 43 20 36 31 20 36
> 37 20 33 44 20 34 44 20 36 35 20 37 34 20 36 35 20 37 32 20 36 35 20 36
> 34 20 34 32 20 36 46 20 36 46 20 36 43 20 36 35 20 36 31 20 36 45 20 32
> 38 20 37 34 20 37 32 20 37 35 20 36 35 20 32 39 20 32 43 20 32 30 20 36
> 39 20 37 30 20 33 44 20 33 31 20 33 30 20 32 45 20 33 33 20 32 45 20 33
> 31 20 32 45 20 33 31 20 33 32 20 37 44 20 30 41 29 5D 0A)]. Processed by
> failure processor:
> Pipeline[Channel[com.visionael.ncm.agent.AgentRouteBuilder
> $SimpleExceptionProcessor@1d82752b],
> Channel[Stop]]
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus