-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter,
On 7/25/17 11:14 AM, Peter Flynn wrote:
> On 24/07/17 11:57, Mark Thomas wrote:
>> On 24/07/17 11:12, Flynn, Peter wrote:
>
> I must apologise first for unintentionally misleading you: the
> upgrade was from Tomcat 7.0.54-2 to 7.0.69-11,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Clemens,
On 7/25/17 9:54 AM, Clemens Eisserer wrote:
> Hi there,
>
> What is the strictest / most conservative setting for
> channelSendOptions when using SimpleTcpCluster for session
> replication (synchronous + ack + ??) ? I have a web-app
On 25/07/17 09:40, Mark Thomas wrote:
> On 25/07/17 08:53, jianjun.guo wrote:
>> In tomcat7 and earlier verison
>> The response content (both response header and body) was put into one buffer
>> before the context will be send to client. So final packet was sent only
>> once commonly.
>>
>>
>>
On 24/07/17 11:57, Mark Thomas wrote:
> On 24/07/17 11:12, Flynn, Peter wrote:
I must apologise first for unintentionally misleading you: the upgrade
was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I inherited this
along with what was clearly bad information.
> Running from a package
Hi there,
What is the strictest / most conservative setting for
channelSendOptions when using SimpleTcpCluster for session replication
(synchronous + ack + ??) ?
I have a web-app where each request dependes on the session-state of
the previous one and unfortunatelyI have to deploy in an
On 25/07/17 08:53, jianjun.guo wrote:
> In tomcat7 and earlier verison
> The response content (both response header and body) was put into one buffer
> before the context will be send to client. So final packet was sent only once
> commonly.
>
>
> In tomcat8.0, exactly, aflter svn version
In tomcat7 and earlier verison
The response content (both response header and body) was put into one buffer
before the context will be send to client. So final packet was sent only once
commonly.
In tomcat8.0, exactly, aflter svn version 1358055, the feature was removed.
when the response
