camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Chandler <a...@riftware.com>
Subject Re: Mina blows up
Date Thu, 08 Apr 2010 18:52:13 GMT
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 <andy@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]]
> > >
> > 
> > 
> > 
> 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message