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 <a...@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 > > > $simpleexceptionproces...@1d82752b], > > > Channel[Stop]] > > > > > > > > > > >
