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 <[email protected]> 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 <[email protected]> > >> > > 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]] > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > >> > > > > > > > > >
