Ok. We do lock all our calls to Basic.sendBinary(), also it seems like
moving to Tomcat 8.5 fixes the issue. No proof yet why. Since it always
happens on our last write out to a client which should trigger a client
ack, the client will immediately send an ack back to us (which seems to
trigger the
On 29/03/17 04:04, Robert Lewis wrote:
> Thanks Mark. I will take a look at the test you linked in (seems like Clint
> already is).
>
> I have a question regarding your previous note "The short version is that
> it is possible that there are two threads". On 8.0.38, doWrite() sets it's
> scoped ha
Thanks Mark. I will take a look at the test you linked in (seems like Clint
already is).
I have a question regarding your previous note "The short version is that
it is possible that there are two threads". On 8.0.38, doWrite() sets it's
scoped handler and buffers to the class level instance, then
rch 28, 2017 3:47 PM
To: Tomcat Users List
Subject: Re: Tracking down a Basic.sendBinary() issue
On 28/03/17 00:30, Robert Lewis wrote:
> Hi,
>
> I am tracking down a fairly sporadic bug in our software that uses
> Tomcat 8.0.38. Long story short, sometimes calls to Basic.sendBinary()
On 28/03/17 00:30, Robert Lewis wrote:
> Hi,
>
> I am tracking down a fairly sporadic bug in our software that uses Tomcat
> 8.0.38. Long story short, sometimes calls to Basic.sendBinary() to a full
> buffer then to a small buffer (eg. 8192x3 then 444 bytes). The first 8192
> sends will succeed an
Hi,
I am tracking down a fairly sporadic bug in our software that uses Tomcat
8.0.38. Long story short, sometimes calls to Basic.sendBinary() to a full
buffer then to a small buffer (eg. 8192x3 then 444 bytes). The first 8192
sends will succeed and occasionally we see the last 444 byte send 'fail'
Hi,
I am tracking down a fairly sporadic bug in our software that uses Tomcat
8.0.38. Long story short, sometimes calls to Basic.sendBinary() to a full
buffer then to a small buffer (eg. 8192x3 then 444 bytes). The first 8192
sends will succeed and occasionally we see the last 444 byte send 'fail'
