camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Mina blows up
Date Fri, 09 Apr 2010 03:56:11 GMT
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 <andy@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 <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]]
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>
>



-- 
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

Mime
View raw message