You didn't optimise as we suggested in the end, you're still building the
content up in memory. As suggested by a few, write to a stream so nothing needs
to consume your clients memory and will scale better
Sent from my iPhone
> On 3 Mar 2015, at 22:06, Alessandro Manzoni
> wrote:
>
> Il 03.
And that's kind of correct.
application/xml does not care of charset. but text/xml does.
On Tue, Mar 3, 2015 at 5:06 PM, Alessandro Manzoni <
manzoni.alessand...@gmail.com> wrote:
> Il 03.03.2015 09.47, Alexey Panchenko ha scritto:
>
>> I am curious about how the client code looks now, before we
Il 03.03.2015 09.47, Alexey Panchenko ha scritto:
I am curious about how the client code looks now, before we continue
complaining on the other end.
Just trying to be fair.
1 HttpClient httpclient = new DefaultHttpClient();
2 HttpPost httppost = new HttpPost(uri);
3
I am curious about how the client code looks now, before we continue
complaining on the other end.
Just trying to be fair.
On Tue, Mar 3, 2015 at 2:36 PM, Brett Ryan wrote:
>
> > What confused me, is that I thought that tomcat should honor the
> encoding set inside xml, while it just use content
> What confused me, is that I thought that tomcat should honor the encoding set
> inside xml, while it just use content-type encoding or its default one
> instead.
Thats the correct behaviour. Your servlet container may choose to inspect the
POST data but there is no requirement for it to, tha
Il 02.03.2015 21.45, Brett Ryan ha scritto:
Hah. If it wasn't for that greek letter we wouldn't have been able to help you
optimise your code, and the bug could have come up at a far more dire time in
production.
Yes indeed. Further more, as at test time the bug didn't come up (due to
a limite
Hah. If it wasn't for that greek letter we wouldn't have been able to help you
optimise your code, and the bug could have come up at a far more dire time in
production.
Sent from my iPhone
> On 3 Mar 2015, at 03:27, Alessandro Manzoni
> wrote:
>
> Il 02.03.2015 17.18, Brett Ryan ha scritto:
Il 02.03.2015 17.18, Brett Ryan ha scritto:
Actually its not tomcats issue, when sending an encoding other than the default
which is ISO-8859-1 according to RFC-2616 (HTTP/1.1) you should send the
encoding type (i.e. text/xml;charset=utf-8). By default the JAXB marshaller
will use UTF-8 encodi
Actually its not tomcats issue, when sending an encoding other than the default
which is ISO-8859-1 according to RFC-2616 (HTTP/1.1) you should send the
encoding type (i.e. text/xml;charset=utf-8). By default the JAXB marshaller
will use UTF-8 encoding when marshalling.
You can switch Tomcat to
what's the encoding used by the tomcat jvm? If it's let's say ISO 8859-1 that
would explain everything.
Sendt fra min iPhone
> Den 2. mar. 2015 kl. 11.45 skrev Alessandro Manzoni
> :
>
> Using InputStreamEntity and forcing UFF-8 as enconding in HttpPost the
> problem was solved. InputStreamE
Using InputStreamEntity and forcing UFF-8 as enconding in HttpPost the
problem was solved. InputStreamEntity only, without UFF-8, was not
enough. That's sond definitively as a Tomcat issue.
Il 26.02.2015 13.35, Oleg Kalnichevski ha scritto:
On Thu, 2015-02-26 at 13:28 +0100, Alessandro Manzon
Il 26.02.2015 17.22, Brett Ryan ha scritto:
I thought Oleg pointed this out already.
If you build up a byte array for your request that byte array must fully occupy
local memory, streaming this will both send data to the host as its constructed
directly from the marshaller which is not only mo
I thought Oleg pointed this out already.
If you build up a byte array for your request that byte array must fully occupy
local memory, streaming this will both send data to the host as its constructed
directly from the marshaller which is not only more efficient but will rule out
any issue resu
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 :
> Il 26.02.2015 11.59, Stefan Magnus Landrø ha scritto
Thank you very much,
Il 26.02.2015 13.33, Oleg Kalnichevski ha scritto:
On Thu, 2015-02-26 at 13:06 +0100, Alessandro Manzoni wrote:
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 proce
Hi,
IMHO the problem is in this line:
StringEntity entity = new StringEntity(new String(output.toByteArray()),
ContentType.TEXT_XML);
Charset is not specified when constructing a String instance, so a system
default one is used, most likely UTF-8 on linux.
And then StringEntity wants to have byt
On Thu, 2015-02-26 at 13:28 +0100, Alessandro Manzoni wrote:
> Thank you Oleg,
> Il 26.02.2015 09.52, Oleg Kalnichevski ha scritto:
> > On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote:
> >>> Since I produce the xml in memory, that's the way Marshal.marshal method
> >>> works, I could use the B
On Thu, 2015-02-26 at 13:06 +0100, Alessandro Manzoni wrote:
> 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
Thank you Oleg,
Il 26.02.2015 09.52, Oleg Kalnichevski ha scritto:
On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote:
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 ma
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
or a tcp dump if you prefer. Could it be a transfer encoding issue? Is
there a proxy involved in this process?
2015-02-26 9:50 GMT+01:00 Oleg Kalnichevski :
> 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 se
On Thu, 2015-02-26 at 20:26 +1100, Brett Ryan wrote:
> > On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote:
> >>> 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
> On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote:
>>> 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.
>>
>>
>> Could you not do something like
>>
On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote:
> > 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.
>
>
> Could you not do something like
>
> Piped
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 >> :
> >> Il 25.02.2015 1
> 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.
Could you not do something like
PipedOutputStream out = new PipedOutputStream();
InputStream instr = new
Hi Stefan,
thank you for the reply,
Il 25.02.2015 20.44, Stefan Magnus Landrø ha scritto:
2015-02-25 20:07 GMT+01:00 Alessandro Manzoni
:
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
2015-02-25 20:07 GMT+01:00 Alessandro Manzoni :
> 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.
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. Docs says
that ByteArrayEntity
Few questions:
Why not use a more appropriate entity type? ByteArrayEntity? StreamEntity?
How do you consume the response?
Sendt fra min iPhone
> Den 25. feb. 2015 kl. 17.26 skrev Alessandro Manzoni
> :
>
> I made a simple client that sends a xml stream to a webapp running on tomcat
> 7
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 re
31 matches
Mail list logo
