Try http://www.tcpdump.org/manpages/tcpdump.1.html in case the simple wire logging thing doesn't work out for you. You can restrict interface and destination port to reduce impact on production.
2015-02-26 13:06 GMT+01:00 Alessandro Manzoni <[email protected] >: > Il 26.02.2015 11.59, Stefan Magnus Landrø ha scritto: > >> or a tcp dump if you prefer. Could it be a transfer encoding issue? Is >> there a proxy involved in this process? >> > The error is returned only with certain post (I noticed that only posts > >30KB are rejected), while the encoding is always the same as posts that > are succesfully accepted. > There is no proxy, the target Tomcat is on the same machine. > How can I dump tcp? It's a production server, do you mean to trace > ethernet headers? As I told you both client and target tomcat are on the > same machine, I don't know any utility able to trace localhost traffic. Can > you advise one? > > > >> 2015-02-26 9:50 GMT+01:00 Oleg Kalnichevski <[email protected]>: >> >> On Thu, 2015-02-26 at 08:26 +0100, Alessandro Manzoni wrote: >>> >>>> Hi Stefan, >>>> thank you for the reply, >>>> >>>> Post a wire log of the session exhibiting the problem. >>> >>> Oleg >>> >>> Il 25.02.2015 20.44, Stefan Magnus Landrø ha scritto: >>>> >>>>> 2015-02-25 20:07 GMT+01:00 Alessandro Manzoni < >>>>> >>>> [email protected] >>> >>>> : >>>>>> Il 25.02.2015 19.28, Stefan Magnus Landrø ha scritto: >>>>>> >>>>>> Few questions: >>>>>>> >>>>>>> Why not use a more appropriate entity type? ByteArrayEntity? >>>>>>> >>>>>> StreamEntity? >>> >>>> Should I? Why an entity would be more or less appropriate? >>>>>> >>>>>> By the way, in version 4.2.2 I have no StreamEntity class. >>>>>> >>>>> >>>>> https://github.com/apache/httpcore/blob/4.2.2/httpcore/ >>> src/main/java/org/apache/http/entity/InputStreamEntity.java >>> >>>> >>>>> Docs says that ByteArrayEntity has no encoding, while StringEntity >>>>>> >>>>> does. >>> >>>> That's it. >>>>>> >>>>>> You're reading the whole thing into memory. You'll get better >>>>> >>>> performance >>> >>>> streaming. The encoding header can be set directly on the request. See >>>>> sources for details on which headers are set in case of string entity. >>>>> >>>> I saw that if a null encoding is used, StringEntity uses a default one, >>>> that works just as expected with small (< 30kb) xml, so I have no >>>> reasons not to trust it. >>>> >>>> Since I produce the xml in memory, that's the way Marshal.marshal method >>>> works, I could use the ByteArrayEntity using the byte[] from the >>>> ByteArrayOutputStream supplied to marshal. But docs tell me that >>>> ByteArrayEntity is not thread-safe, while I need to use HttpClient by >>>> conncurrent threads. >>>> >>>> Further more, I supect that the target Tomcat dislikes my request due to >>>> incongruents content and content-lenght or a buffer too small somewhere. >>>> I don't see anything to do with the entity that matches this figure. >>>> >>>> Tomcat logs do not show anything about the reason not to accept the >>>> request. >>>> I need some hint to investigate further, maybe just to say it's not >>>> HTTPClient fault. >>>> >>>>> Fair enough. You should see details in the tomcat logs concerning the >>>>> >>>> 400 >>> >>>> error code. Are you controlling the application you're hitting? >>>>> >>>> Not directly, just logs. >>>> I was told that target application logs received requests as soon as is >>>> invoked and always replies with an xml carrying an error indicating >>>> failing items. When the problem arise, I don't find any log about, and >>>> the only response received is tomcat error page. >>>> Then when Tomcat reject the request, usully is because of an uncathed >>>> exception (that cause a 500 reason code, and the exception appears in >>>> tomcat logs) or some filter prevent to invoke the target application >>>> (but I should see this in tomcat logs and reason code would be some 40x >>>> reason code but 400), or it evaluate the request as malformed (that >>>> resuts in a 400 reson code). Isn't it? >>>> >>>>> By the way, I try to unmarshal response.getEntity().getContent(), as >>>>>> >>>>> the >>> >>>> application waits for a returned xml stream. >>>>>> If the unmarshal fails, I just write the content to the log file. In >>>>>> >>>>> the >>> >>>> log I found that Tomcat returned an html page, with the notification >>>>>> >>>>> of the >>> >>>> failure. This case 400 bad request, and I'm wondering why Tomcat >>>>>> >>>>> dislikes >>> >>>> my request. That's not bad at all to me. >>>>>> >>>>>> Den 25. feb. 2015 kl. 17.26 skrev Alessandro Manzoni < >>>>>> >>>>>>> [email protected]>: >>>>>>>> >>>>>>>> I made a simple client that sends a xml stream to a webapp running >>>>>>>> >>>>>>> on >>> >>>> tomcat 7 by POST method. >>>>>>>> Both client and tomcat run on the same server (linux). HTTPClient >>>>>>>> version is 4.2.2. >>>>>>>> >>>>>>>> The xml stream is formally correct. Somtimes, when the stream is >>>>>>>> >>>>>>> more >>> >>>> than 30KB tomcat replies with an html page reporting 400 bad >>>>>>>> >>>>>>> request. When >>> >>>> the stream is smaller goes fine. >>>>>>>> >>>>>>>> This is my code: >>>>>>>> HttpClient httpclient = new DefaultHttpClient(); >>>>>>>> HttpPost httppost = new HttpPost(uri); >>>>>>>> StringEntity entity = new StringEntity(new >>>>>>>> String(output.toByteArray()), ContentType.TEXT_XML); >>>>>>>> httppost.setEntity(entity); >>>>>>>> return httpclient.execute(httppost); >>>>>>>> >>>>>>>> where: >>>>>>>> - uri is the uri of the webapp, always the same. >>>>>>>> - output is a ByteArrayOutputStream that contains the xml stream >>>>>>>> >>>>>>>> Should I put some more headers? Or change somewhat to avoid the >>>>>>>> >>>>>>> error? >>> >>>> Thanks, regards. >>>>>>>> >>>>>>> ------------------------------------------------------------ >>>> --------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com
