Re: Server giving 404 since upgrade to Tomcat7

2017-07-25 Thread Christopher Schultz 
-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, not from 6 to 7. I
> inherited this along with what was clearly bad information.

Thanks for the clarification.

>> Running from a package tends to limit the members of this that
>> are available to help to those that understand the packaging on
>> the platform in question.
> 
> I'm afraid so. But I hope this is not about packaging, but about 
> modifying the configuration.

Probably so, especially because it was a minor version upgrade.

>> Tomcat needs allowLinking to be correctly set if that path to a
>> web application (or the web application itself) uses symlinks. I
>> don't think that has changed between 6.0.x and 7.0.x.
> 
> There seem to be two, but I have never used or touched examples.
> 
> # find /var/lib/tomcat/webapps -type l -ls 5369297260
> lrwxrwxrwx   1 tomcat   tomcat 40 Aug 11  2016 
> /var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar -> 
> /usr/share/java/jakarta-taglibs-core.jar 5369297270 lrwxrwxrwx
> 1 tomcat   tomcat 44 Aug 11  2016 
> /var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar -> 
> /usr/share/java/jakarta-taglibs-standard.jar

That looks like the package manager's doing, and is probably okay. If
it's not okay, then complain to the package manager that they have
broken their own package :) (And the package manager happens to be
reading this thread, so you should be good, here.)

>>> # In new-style instances, if CATALINA_BASE isn't specified, it
>>> will # be constructed by joining TOMCATS_BASE and NAME.
>> 
>> Those last two variables are package specific.
> 
> What is a 'package' in this context? A Tomcat application?

Mark was referring to the Tomcat "package" as packaged by the package
manager (e.g. yum).

In this case, Tomcat itself doesn't do anything with environment
variables called TOMCAT_HOME or NAME. Tomcat only cares about
CATALINA_BASE (where instance-specific configuration and webapps are
kept) and CATALINA_HOME (which is where the base Tomcat files can be
found).

>> The Tomcat logs should at least tell you what - if anything -
>> Tomcat is deploying.
> 
> If I can make sense of them...
> 
>> There is no one 'right' way to install Tomcat. Pick the one that
>> works best for you (and be prepared to try an alternative if you
>> hit problems).
> 
> :-) I'd rather compile from scratch, but that's just the way I was 
> brought up.

Building Tomcat from source is a waste of your time: the official
packages (both from ASF and from Red Hat) have all been built for you
and are environment agnostic. I would never recommend that anyone
build Tomcat themselves unless they are trying to hack on it for their
own needs.

Let's try this:

1. Stop Tomcat and remove all log files (or push them somewhere else
out of the way)
2. Launch Tomcat (and please tell us how you do that)
3. Make a single request that returns 404 but should not
4. Stop Tomcat
5. Post the contents of logs/catalina.out to the list

Please remove any secrets that might be in that file (the only secrets
that might be in there would be coming from your application).

I saw your log file snippets, but there might be something you missed
(since the log was incomplete).

I've used Apache Cocoon with Tomcat 4.x and later and haven't had any
problems like you describe. I suspect this is a simple configuration
problem that we can help you get corrected.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZd5VXAAoJEBzwKT+lPKRY0i8QAKdDAO9Dx+ilxET2wuRNiJCy
IQkjVcc1T5GPxNWpdIJIA/i8+5lhsUT6+BJy77hEsIjAfeGIAXbywylMUAv/i/Oo
Ixgwb+NkzZ38dW14b8Y+QmtJ2qP/aM9q1TvlxS9/AxIk+sT7dl6jQucZsYM1NqSI
HgGwqXtgvs3Rzzcq+0SNqDrDVsEW486cCFqnw8pboCYAGzUkpLY2zOApjQLD30cR
U7DrGgYNzThcXngusKFuK2AWU6DDx0mIkKFxArtXWLFJr0prk4pM+BWdXQH8FGac
kdX/pu7ryaCjeQ/QztWGHsA4W9CplRlCTxhWRIQwiY86auwYGis55yVZ1jzuXGdi
IY17e3Sdnmo8GFjfTaUSxJIpquRW/+GqApe/yia2vL1Vr6Pbztu/7IMxEw13iHfF
eyvY9haDBFrdrvINBtAj8FW5K8WL41PAaHsXV5R67nMyx2yQ0Nd/G/aXFikrqn4R
T8tQNfyTt2ZaExsySU4oNSpejSjAolRX8AqvS7/aexEN+zRC3MePNOgS6AuuxBEe
7LIe3Si0JW7+2gYShgCYMPSK5w7fJzGJrHqbTlJPlqf38w2bj511s4K9fKYsbPcp
PkkYAlGSU3tn53gk4crbOSjceGEWZKj4byvvldSjDyG3NdhMrjjQI8C7+fYXSqBI
d39WE9U7+Dqt1Fi+gJYC
=NjvT
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Most strict / conservative setting for SimpleTcpCluster - channelSendOptions

2017-07-25 Thread Christopher Schultz 
-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 where each
> request dependes on the session-state of the previous one and
> unfortunatelyI have to deploy in an environment where a round-robin
> load-balancer is used.

What happens if the user makes two requests at once?

> I had a look at the documentation (the examples online were not
> that clear - in the docs it is only mentioned 8 is async, whereas 6
> is later used without any explanation), however to be honest I am
> not sure which combination I actually require.

The channelSendOptions are a bitwise-OR'd combination of flags. Each
flag is a certain power of two (a single 1 bit) so if you see a value
that isn't a power of two (like 6), then you need to decompose that
number into its parts:

6 = 0110b
 ^^
 |+-- 0010 = 2 = "Use Ack"
 +--- 0100 = 4 = "Synchronized Ack"

So channelSendOptions="6" means "use ack, and use synchronized ack".

I'm not expert, but it seems you really only have two options:

1. Use ACK (yes/no)
and
2. If you use ACK, do you want them to be synchronous or asynchronous

I'm not sure why there are 3 options, here, since 2 of them make no
sense when the "Use ACK" is not set.

For a "conservative" configuration (where, I believe you mean that you
want to guarantee delivery and as much consistency as possible, at the
cost of performance), I believe you want "Use ACK" and "Sync ACK"
which would be that value of "6" you mentioned earlier.

- -chris

References:
https://tomcat.apache.org/tomcat-8.0-doc/config/cluster.html#Attributes

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZd5J9AAoJEBzwKT+lPKRYNDkP/R8mOo0rnC6nfUzP/VH1N9Qw
5hrh/nEqNv8rpE6WHoVcZUMlPvZJ1TBLF+2N6WvE4to218gzTrfXz+9pGvStxDYH
fclJ4mUn8LGj3yrLz9/7s1LhB0NeWVznmpnmoNJmcbnB6QEVjwpACIZ8SwkN6pjr
JwQWLf6rENcdbhsBLpEK8+j2s/hHoJpH5qAbK8yYa7Q2ZOypVswrg8fj9tDVJ/sy
6+wVPkECB5cJZyNMMPQl7qMzVmTDnB4hKLYRKmzVMr99hVOjuh3jq05Q0PE4dWy8
o6+YuzTwM4IAX20YA42qhs/qDtEozP2VRcrcw/PXlf/TIy7gRYpcIwbL5Yo4Fk3s
s5ytp4EWhxvDHN0t2fTC4eVV9SYLlJAK5voDqIIFzjqu7l7hNFB9PETj6xvE0jHo
KaxdbDXastiNQeHEQFiP3r03PR+C0dLl38BRdxUVRGj8mrpwt2ouLauxNQ1AyInd
ygCDDB/Zqv+RJuM3JFSTE5c1+h8Ux8GtXbW5WDnCwEvjTWYVrLNQcdxNCLpaFqa8
aQdGKKK0YCFdlh5eR9HiDRdC1dnoECAePpK78rHjwIblIit/ov3V7PkYmZVZ/69h
2sSOBVi3KYz/D6uuCHHXVMGxlfcqrEf2jP+1smvVGC/xONQMXI+2K1MwxXH7dgKy
jzpmx6sXWsurDHM1Cj8w
=H4JM
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: The performance reduce much for tomcat 8 ？

2017-07-25 Thread Mark Thomas 
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.
>>
>>
>> In tomcat8.0, exactly, aflter svn version 1358055,  the feature was removed. 
>> when the response was commited, the packet that only contains response header
>> was send to client alonely.
>>
>>
>> For any http request, socket write twicely at the least.
> 
> Thanks for the further investigation.
> 
> I've done a quick test with 9.0.x and 8.0.x and I also see this
> behaviour with 8.0.x but not 9.0.x. I haven't looked deeper to see if it
> is connector specific or what the root cause might be.  I plan to do
> that next.

I've spent some time looking into this and it does appear to be Tomcat
8.0.x specific.

The connector refactoring in 8.5.x/9.0.x restored the buffering by
default behaviour of 7.0.x.

I've looked at the HTTP connectors, but not the AJP connectors. Of the
HTTP connectors, NIO and APR look to be affected but not BIO or NIO2.
The socketBuffer connector attribute only affects BIO.

In theory, it should be possible to patch NIO and APR. Based on the
later refactoring, the starting point is probably
Internal[Nio|Apr]OutputBufer#addToBB().

Looking at a patch for this is not a priority for me at the moment
although I'd be happy to review a patch if someone wanted to offer one.
I think the changes can be contained to #addToBB() but that is based on
a fairly quick review. I might have missed something - particularly
related to non-blocking handling.

Mark


> 
> Mark
> 
>> -- Original --
>> From:  "Mark Thomas";
>> Date:  Mon, Jul 24, 2017 09:02 PM
>> To:  "Tomcat Users List"; 
>>
>> Subject:  Re: The performance reduce much for tomcat 8 ??
>>
>>  
>> On 24/07/17 13:01, jianjun.guo wrote:
>>> thanks for reply .
>>>  The same scenario and the same configuration, i test  tomcat 8.0.45 and 
>>> tomcat 8.5.16 again.
>>>  tomcat 8.0.45  and tomcat8.0.32 have almost same performance??
>>>  tomcat 8.5.16  and tomcat7.0.39 have almost same performance??
>>>  Because my test case is very simple http request , big performance 
>>> fluctuation may be caused by a little synchronized operation.
>>>  
>>> I found it thread stack the synchronized code in 
>>> InternalNioOutputBuffer.java:
>>> private synchronized void addToBB(..)??  synchronized  is must?
>>
>> svn blame is a useful command that can help point to the commit
>> responsible for any given change.
>>
>> Sometimes (as in this case) you need to go back more than one change to
>> the line in question to find the reason for a specific change.
>>
>> Alternatively, you can do the same thing via the viewvc interface.
>> https://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/
>>
>> Mark
>>
>>
>>>
>>>
>>> i will test and verify it if the impact come from here.
>>>
>>>
>>> Thanks.
>>>  
>>> -- Original --
>>> From:  "Mark Thomas";
>>> Date:  Mon, Jul 24, 2017 04:29 PM
>>> To:  "Tomcat Users List"; 
>>>
>>> Subject:  Re: The performance reduce much for tomcat 8 ??
>>>
>>>  
>>> On 24/07/17 09:18, jianjun.guo wrote:
 Hi,
 I deployed a very simple jsp page to test the performance for tomcat7 vs 
 tomcat8.


 The same scenario and the same configuration?? The TPS for tomcat7.0.39 is 
 8.3W, but for tomcat8.0.32 only 6.1W??


 There is a big difference for them?  Thanks for your help.
>>>
>>> It is hard to comment without knowing the details of the application
>>> that was deployed.
>>>
>>> I don't recognise the units used for the results.
>>>
>>> 7.0.39 was released roughly 3 years earlier than 8.0.32. It is possible
>>> that bug fixes applied to 7.0.x and 8.0.x have impacted performance in
>>> some way.
>>>
>>> It is also over a year since 8.0.32 was released. Performance
>>> differences between the latest 7.0.x and 8.5.x releases (or 9.0.x) are
>>> more likely to be investigated.
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:

Re: Server giving 404 since upgrade to Tomcat7

2017-07-25 Thread Peter Flynn 
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 tends to limit the members of this that are 
> available to help to those that understand the packaging on the
> platform in question.

I'm afraid so. But I hope this is not about packaging, but about
modifying the configuration.

> Tomcat needs allowLinking to be correctly set if that path to a web
> application (or the web application itself) uses symlinks. I don't think
> that has changed between 6.0.x and 7.0.x.

There seem to be two, but I have never used or touched examples.

# find /var/lib/tomcat/webapps -type l -ls
5369297260 lrwxrwxrwx   1 tomcat   tomcat 40 Aug 11  2016
/var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar ->
/usr/share/java/jakarta-taglibs-core.jar
5369297270 lrwxrwxrwx   1 tomcat   tomcat 44 Aug 11  2016
/var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar ->
/usr/share/java/jakarta-taglibs-standard.jar

>> # In new-style instances, if CATALINA_BASE isn't specified, it will
>> # be constructed by joining TOMCATS_BASE and NAME.
> 
> Those last two variables are package specific.

What is a 'package' in this context? A Tomcat application?

> The Tomcat logs should at least tell you what - if anything - Tomcat is
> deploying.

If I can make sense of them...

> There is no one 'right' way to install Tomcat. Pick the one that works
> best for you (and be prepared to try an alternative if you hit problems).

:-) I'd rather compile from scratch, but that's just the way I was
brought up.

On 24/07/17 14:50, Coty Sutherland wrote:
[...]
> In my experience, a 404 after an update (with no other application 
> changes) suggests that the application failed deployment. Can you 
> verify that you don't see any exceptions in your log?
I would if I knew what to look for :-) In /var/log/tomcat there are:

 • a catalina.out but it's empty
 • hundreds of host-manager.-mm-yy.log, all empty
 • hundreds of localhost.-mm-yy.log, all empty
 • hundreds of localhost_access_log.-mm-dd.txt, between 10–20MB each
 • dozens of catalina.out-mmdd.gz, 20 or so bytes each
 • dozens of catalina.-mm-dd.log, 30-100KB each
 • one catalina.out, empty

I realise this is probably CentOS's or RedHat's doing :-)

A typical catalina.-mm-dd.log starts with

> Jul 25, 2017 7:55:01 AM org.apache.catalina.core.StandardServer await
> INFO: A valid shutdown command was received via the shutdown port. Stopping 
> the Server ins
> tance.
> Jul 25, 2017 7:55:01 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-bio-8080"]
> Jul 25, 2017 7:55:05 AM org.apache.catalina.core.AprLifecycleListener init
> INFO: The APR based Apache Tomcat Native library which allows optimal 
> performance in produ
> ction environments was not found on the java.library.path: 
> /usr/java/packages/lib/amd64:/u
> sr/lib64:/lib64:/lib:/usr/lib
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule 
> begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 
> 'xmlValidation'
> to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule 
> begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 
> 'xmlNamespaceAwa
> re' to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule 
> begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 
> 'xmlValidation'
> to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule 
> begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 
> 'xmlNamespaceAwa
> re' to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule 
> begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 
> 'xmlValidation'
> to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.tomcat.util.digester.SetPropertiesRule 
> begin
> WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 
> 'xmlNamespaceAwa
> re' to 'false' did not find a matching property.
> Jul 25, 2017 7:55:05 AM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["http-bio-8080"]
> Jul 25, 2017 7:55:05 AM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
> Jul 25, 2017 7:55:05 AM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 586 ms
> Jul 25, 2017 7:55:05 AM org.apache.catalina.core.StandardService startInternal
> INFO: Starting service Catalina
and eventually gets round to

>

Most strict / conservative setting for SimpleTcpCluster - channelSendOptions

2017-07-25 Thread Clemens Eisserer 
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 environment
where a round-robin load-balancer is used.

I had a look at the documentation (the examples online were not that
clear - in the docs it is only mentioned 8 is async, whereas 6 is
later used without any explanation), however to be honest I am not
sure which combination I actually require.

Thank you in advance, Clemens

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: The performance reduce much for tomcat 8 ？

2017-07-25 Thread Mark Thomas 
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 1358055,  the feature was removed. 
> when the response was commited, the packet that only contains response header
> was send to client alonely.
> 
> 
> For any http request, socket write twicely at the least.

Thanks for the further investigation.

I've done a quick test with 9.0.x and 8.0.x and I also see this
behaviour with 8.0.x but not 9.0.x. I haven't looked deeper to see if it
is connector specific or what the root cause might be.  I plan to do
that next.

Mark

> -- Original --
> From:  "Mark Thomas";
> Date:  Mon, Jul 24, 2017 09:02 PM
> To:  "Tomcat Users List"; 
> 
> Subject:  Re: The performance reduce much for tomcat 8 ??
> 
>  
> On 24/07/17 13:01, jianjun.guo wrote:
>> thanks for reply .
>>  The same scenario and the same configuration, i test  tomcat 8.0.45 and 
>> tomcat 8.5.16 again.
>>  tomcat 8.0.45  and tomcat8.0.32 have almost same performance??
>>  tomcat 8.5.16  and tomcat7.0.39 have almost same performance??
>>  Because my test case is very simple http request , big performance 
>> fluctuation may be caused by a little synchronized operation.
>>  
>> I found it thread stack the synchronized code in 
>> InternalNioOutputBuffer.java:
>> private synchronized void addToBB(..)??  synchronized  is must?
> 
> svn blame is a useful command that can help point to the commit
> responsible for any given change.
> 
> Sometimes (as in this case) you need to go back more than one change to
> the line in question to find the reason for a specific change.
> 
> Alternatively, you can do the same thing via the viewvc interface.
> https://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/
> 
> Mark
> 
> 
>>
>>
>> i will test and verify it if the impact come from here.
>>
>>
>> Thanks.
>>  
>> -- Original --
>> From:  "Mark Thomas";
>> Date:  Mon, Jul 24, 2017 04:29 PM
>> To:  "Tomcat Users List"; 
>>
>> Subject:  Re: The performance reduce much for tomcat 8 ??
>>
>>  
>> On 24/07/17 09:18, jianjun.guo wrote:
>>> Hi,
>>> I deployed a very simple jsp page to test the performance for tomcat7 vs 
>>> tomcat8.
>>>
>>>
>>> The same scenario and the same configuration?? The TPS for tomcat7.0.39 is 
>>> 8.3W, but for tomcat8.0.32 only 6.1W??
>>>
>>>
>>> There is a big difference for them?  Thanks for your help.
>>
>> It is hard to comment without knowing the details of the application
>> that was deployed.
>>
>> I don't recognise the units used for the results.
>>
>> 7.0.39 was released roughly 3 years earlier than 8.0.32. It is possible
>> that bug fixes applied to 7.0.x and 8.0.x have impacted performance in
>> some way.
>>
>> It is also over a year since 8.0.32 was released. Performance
>> differences between the latest 7.0.x and 8.5.x releases (or 9.0.x) are
>> more likely to be investigated.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: The performance reduce much for tomcat 8 ??

2017-07-25 Thread jianjun.guo 
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 was commited, the packet that only contains response header
was send to client alonely.


For any http request, socket write twicely at the least.










 
-- Original --
From:  "Mark Thomas";
Date:  Mon, Jul 24, 2017 09:02 PM
To:  "Tomcat Users List"; 

Subject:  Re: The performance reduce much for tomcat 8 ??

 
On 24/07/17 13:01, jianjun.guo wrote:
> thanks for reply .
>  The same scenario and the same configuration, i test  tomcat 8.0.45 and 
> tomcat 8.5.16 again.
>  tomcat 8.0.45  and tomcat8.0.32 have almost same performance??
>  tomcat 8.5.16  and tomcat7.0.39 have almost same performance??
>  Because my test case is very simple http request , big performance 
> fluctuation may be caused by a little synchronized operation.
>  
> I found it thread stack the synchronized code in InternalNioOutputBuffer.java:
> private synchronized void addToBB(..)??  synchronized  is must?

svn blame is a useful command that can help point to the commit
responsible for any given change.

Sometimes (as in this case) you need to go back more than one change to
the line in question to find the reason for a specific change.

Alternatively, you can do the same thing via the viewvc interface.
https://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/

Mark


> 
> 
> i will test and verify it if the impact come from here.
> 
> 
> Thanks.
>  
> -- Original --
> From:  "Mark Thomas";
> Date:  Mon, Jul 24, 2017 04:29 PM
> To:  "Tomcat Users List"; 
> 
> Subject:  Re: The performance reduce much for tomcat 8 ??
> 
>  
> On 24/07/17 09:18, jianjun.guo wrote:
>> Hi,
>> I deployed a very simple jsp page to test the performance for tomcat7 vs 
>> tomcat8.
>>
>>
>> The same scenario and the same configuration?? The TPS for tomcat7.0.39 is 
>> 8.3W, but for tomcat8.0.32 only 6.1W??
>>
>>
>> There is a big difference for them?  Thanks for your help.
> 
> It is hard to comment without knowing the details of the application
> that was deployed.
> 
> I don't recognise the units used for the results.
> 
> 7.0.39 was released roughly 3 years earlier than 8.0.32. It is possible
> that bug fixes applied to 7.0.x and 8.0.x have impacted performance in
> some way.
> 
> It is also over a year since 8.0.32 was released. Performance
> differences between the latest 7.0.x and 8.5.x releases (or 9.0.x) are
> more likely to be investigated.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org