Re: Performance regression from 7 to 8
Aurélien, On 3/9/16 10:53 AM, Aurélien Terrestris wrote: > thanks for this information, but Tullio said that his problem only occurs > with the NIO connector (it seems weird and I don't have sufficient > knowledge on how it is coded in Tomcat anyway). > > The post was already quite long before I suggested him to try both > connectors to identify a possible problem there. I'm just being pragmatic > here. Sure. I was just pointing out that mitigating this "performance regression" (which has yet to be seen outside his own personal environment) by switching connectors is only going to work until he upgrades to the next version of Tomcat, where that strategy isn't going to work. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: disable Set-Cookie http-only in tomcat 8
Hi, 2016-03-09 17:48 GMT+02:00 Rajesh Cherukuri : > > Hi > I was trying to disable httponly in the setcookie header from tomcat > reponse , can some one let me know how to disable it > > > > i have tried these 2 but didn't help me > > > > > > 1.) web.xml > > > > > false > > > > > > > > 2.) context.xml > > > useHttpOnly="false" > Did you specify this as an attribute? ... Regards, Violeta > curl -I http://localhost:8801 > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Set-Cookie: JSESSIONID=7A54CAEC2733B3AB015ED09F9A68C72A; Path=/; *HttpOnly* > Content-Type: text/html;charset=ISO-8859-1 > Content-Length: 305 > Date: Wed, 09 Mar 2016 15:41:48 GMT > > > > *Server version: Apache Tomcat/8.0.30Server built: Dec 1 2015 22:30:46 > UTC* > Server number: 8.0.30.0 > OS Name:Linux > OS Version: 3.10.0-229.el7.x86_64 > Architecture: amd64 > JVM Version:1.8.0_73-b02 > JVM Vendor: Oracle Corporation
Re: Intermittent ClassNotFoundException in Jasper EL evaluation
On 09/03/2016 18:20, jimi.hulleg...@svensktnaringsliv.se wrote: > Has anyone seen this problem before? What could be the cause of it? It is a known 'feature' of the new EL requirements added in 3.0. The EL parser can't differentiate between an attribute without a scope and a reference to an static field. See https://bz.apache.org/bugzilla/show_bug.cgi?id=57583 The way to avoid it is to always add an explicit scope (page, request, application, session) to your attributes. Suggestions for improvements to the default ImportHandler implementation to make this faster are welcome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mapping servlet to non English url pattern
On Wed, Mar 9, 2016 at 7:46 PM, Mark Eggers wrote: > Yuval, > > Notes are inline (I hope). This is quickly becoming a NetBeans question. > > On 3/9/2016 1:38 AM, Yuval Schwartz wrote: > > Thanks Mark, follow up questions below: > > > > On Wed, Mar 9, 2016 at 1:26 AM, Mark Eggers > > > wrote: > > > >> Yuval, > >> > >> On 3/8/2016 2:35 PM, Yuval Schwartz wrote: > >>> On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: > >>> > On 08/03/2016 20:20, Christopher Schultz wrote: > > Yuval, > > > > On 3/8/16 12:38 PM, Yuval Schwartz wrote: > >> Hello Christopher, thanks, responses below. > > > >> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > > > >> Yuval, > > > >> On 3/8/16 3:14 AM, Yuval Schwartz wrote: > > Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > > > > Hello, > > > > I want to map my servlet to a Hebrew url pattern. > > > >> Hmm. > > > > I tried placing the hebrew url pattern both in the > > "@webservlet" annotation (urlpatterns attribute) and in the > > the web.xml file. In both cases it doesn't work, it's as if > > there's nothing mapped to the url specified. > > > > I though to specify the URIEncoding parameter of the > > connector but saw that this defaults to "utf-8" in tomcat 8. > > > >> Yes, it does. > > > >> So you are trying to set the url-pattern for a servlet mapping? > > > >> When you do it -- either using @WebServlet or -- > >> can you connect via JMX to observe the pattern that's been read > >> into the configuration? First, I'd want to make sure that the > >> Hebrew characters haven't been destroyed by the loading process of > >> the XML file or by the compiler, or even by Tomcat. > > > > > >>> Can you give me some direction on how I would do this? Maybe a > >>> little more detail on jmx? There could be encoding/decoding going > >>> on in the browser (firefox) and in all the elements you mentioned > >>> on the server side. Any way to see the final String that the > >>> server is using to match the Url pattern? > > > > Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > > the configuration through it. > > > > Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > > that contains a JMX client... both jconsole and VisualVM require that > > you go to the "plug-ins" configuration and install an > > easy-to-find-and-install plug-in for JMX) on the same machine (it's > > easiest this way). > > > > (I just checked, and VisualVM calls the plug-in > > "VisualVM-MBeans".)visualvisual > > > > Then, connect to the Tomcat instance and go to the BMeans tab. > > > > You'll find your servlet under > >> /Catalina/Servlet/host/context/[servlet]. > > .. > > > > > > Aw, crap. The mappings themselves aren't actually published via JMX. > >> Hmm > > Yes they are. > > You need to look at the operations. findMappings() will list them. > > >>> > >>> I did this and it worked: > >>> The english patterns show up fine, as expected. > >>> The hebrew pattern shows up as a bunch of question marks (eg: > >>> -?-) > >>> The URLEncoded pattern shows up as wierd symbols (eg: diamond shape, tm > >>> symbol). > >>> > >>> Could this be something in my IDE (Netbeans) settings? The logs for > >>> example, display hebrew characters as question marks. Although my > project > >>> encoding is set as UTF-8. > >>> > >>> Thanks. > >>> > >>> > >>> > > Mark > >> > >> Are you developing on Windows? (ah, you are) > >> > >> If so, could you check how you launch NetBeans? My netbeans.conf file > >> contains this on the netbeans_default_options line: > >> > >> -J-Dfile.encoding=UTF-8 > >> > > > > I tried this, still doesn't fix the issue (Although a change is noticed: > > going to help-->about under "system" text changes from "cp1252" to > "UTF-8"). > > > > Good, the change did take. > > If you're working with an existing project, you may have to change the > encoding on that project as well. > > Go to the Properties panel by right-mouse clicking on the project, and > selecting Properties (should be at the bottom, at least it is on > NetBeans 8.1). > > On the Sources panel at the bottom, make sure that the encoding is UTF-8. > > Note that for existing projects you will probably have to change this. > > Also note that for existing files, you'll probably have to do the > following: > > 1. Delete your Hebrew > 2. Outside of NetBeans change that file to UTF-8 > 3. Open in NetBeans > 4. Add the Hebrew > > I know, it's messy, but again NetBeans does not have a plugin to do this > internally. > > > > >> > >> Also, if you're using Maven with NetBeans, UTF-8 has to be set there as > >> well. My projects cont
Re: Mapping servlet to non English url pattern
On Wed, Mar 9, 2016 at 5:38 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Yuval,
>
> On 3/8/16 4:04 PM, Yuval Schwartz wrote:
> > @WebServlet(name="SomeServlet", urlPatterns={"/help/why-no-work",
> > "/iw/help/למה-לא-עובד",
> > "/iw/help/%D7%9C%D7%9E%D7%94-%D7%9C%D7%90-%D7%A2%D7%95%D7%91%D7%93"}
> > (the last pattern is the same as the second to last, just encoded)
>
> I think that last pattern will not be useful, because Tomcat should be
> doing the encoding internally. For example, if you wanted to map a
> servlet to "/foo bar" you wouldn't have to URL-encode it like /foo%20bar
> in the XML file. But I haven't actually tried it.
>
> (from your other post):
>
> On 3/8/16 5:35 PM, Yuval Schwartz wrote:
> > I did this and it worked:
> > The english patterns show up fine, as expected.
> > The hebrew pattern shows up as a bunch of question marks (eg:
> > -?-)
> > The URLEncoded pattern shows up as wierd symbols (eg: diamond shape,
> > tm symbol).
>
> Hmm, that could certainly be a problem with the tool itself (Netbeans?).
> Can you try running with jconsole just to have a (potentially) clean
> environment?
>
Hey, can you clarify a bit? What do you mean "try running with jconsole"?
Run what? As I understand it, JConsole is for monitoring.
>
> The encoded pattern showing up as weird symbols sounds .. odd as well.
> Actually, everything about this sounds weird.
>
> On 3/9/16 4:38 AM, Yuval Schwartz wrote:
> > Are you suggesting I convert all of my source files to UTF-8? Will
> > all new files that are created now be in UTF-8 at least? Because I
> > just created a new servlet for testing purposes (after the
> > -J-Dfile.encoding property was added) and hebrew urls still aren't
> > found.
>
> You definitely don't need to convert your files to UTF-8, but you might
> instead want to use the encoding-proof Unicode escapes instead of the
> raw Hebrew in your source files.
>
> You can use native2ascii to do this for you:
>
> input.txt
> /iw/help/למה-לא-עובד
>
> $ native2ascii -encoding utf8 input.txt
> /iw/help/\u05dc\u05de\u05d4-\u05dc\u05d0-\u05e2\u05d5\u05d1\u05d3
>
> So those are the \u Unicode escapes that you should use in your code.
> Try using those and rebuilding to see if it improves anything.
>
This doesn't work.
>
> -chris
>
Thank you
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Performance regression from 7 to 8
Am 09.03.2016 um 10:12 schrieb Tullio Bettinazzi:
I tested with http11.Http11Protocol, http11.Http11NioProtocol and
http11.Http11Nio2Protocol and the problem reproduces only with
http11.Http11NioProtocol.
It seems to be a bug of the Nio protocol.
It's better to use Nio2 or standard ? What's the difference ?
Maybe Marks webinar will help you:
https://www.youtube.com/watch?v=LBSWixIwMmU
On the other hand, now that you can switch the problems on and off on
the server side, can you try to dig deeper into the problem? Maybe take
a tcpdump from one client that has problems with the nio connector and
compare that to a tcpdump from the same client to the nio2 or bio connector?
Have you identified any other commonalities between clients that expose
problems with the nio connector? Browser, OS, network topology?
Regards,
Felix
Tks
Tullio
Date: Mon, 7 Mar 2016 16:26:24 +0100
Subject: Re: Performance regression from 7 to 8
From: aterrest...@gmail.com
To: users@tomcat.apache.org
Tullio,
as suggested before by Felix, maybe you should try different connector
configurations (defaults for HTTP connector are different between T7
(blocking) and T8 (non-blocking)) and see if this changes anything.
For example in the server.xml file :
and
Your code is simple, only buffering and writing to an OutputStream. Don't
know how, but I believe that only the buffering can introduce some delay.
best regards
2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi :
As I already explained is not a reproductable problem.
I tested the testcase in my environment and I reproduced the problem on
some clients but not on all clients : the same clients where I noticed the
problem in the real application.
I'm not able to understand what's the relevant difference among them (not
OS version, not network, not browser).
The problem disappears using tomcat 7.
Tks
Tullio
Subject: Re: Performance regression from 7 to 8
To: users@tomcat.apache.org
From: ma...@apache.org
Date: Mon, 7 Mar 2016 11:52:40 +
On 06/03/2016 08:45, Tullio Bettinazzi wrote:
I tested with 8.20 and 8.32
With nothing changed I meant simply that results didn't change.
I can't repeat the problem you are describing with your provided test
case.
I ran:
- ab -k -n 1000 -c 1 localhost:8080/user002/Test
- latest 8.0.x code
- your test case with and without setting the content length (as an
HTTP/1.0 client ab needs the content length to use keep-alive with
large response bodies
I saw average response times of 6ms with a maximum of 9ms.
The content length header made no difference (apart from keep-alive
being used as expected).
If the problem you are describing was widespread I'd expect to see other
users reporting this on the mailing list.
Given that:
- I can't repeat this
- Other users aren't reporting it
- Only you are seeing the issue
this looks like an issue with your environment rather than with Tomcat.
I'd recommend using tools like Wireshark and YourKit to find out exactly
what is going on.
Mark
Tks
Tullio
Subject: Re: Performance regression from 7 to 8
To: users@tomcat.apache.org
From: ma...@apache.org
Date: Sat, 5 Mar 2016 18:40:36 +
On 04/03/2016 13:19, Tullio Bettinazzi wrote:
Done and nothing changed.
What has changed is that you have now provided a test case that
someone
else can run easily and confirm, or not, your findings.
Any suggestion ?
Before anyone spends time looking at this the other question I don't
see
answered in this thread is "Exactly which Tomcat 8 version were you
testing?". If it isn't the the latest then you'll need to retest to
confirm the issue hasn't already been fixed.
Mark
Here the code.
package axioma.rubik.engine.web.servlet;
import java.io.*;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
@WebServlet(name="Test8", description="Direct update of data",
urlPatterns={"/Test8"})
public class Test8Servlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Override
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
try {
fai(response);
} catch (Exception ex) {
ex.printStackTrace();
}
}
public void fai(HttpServletResponse response) throws IOException
{
ByteArrayOutputStream bbs = new ByteArrayOutputStream();
BufferedOutputStream bos = new BufferedOutputStream(bbs);
for(int i = 0; i < 40; i++) {
bos.write(96);
}
bos.flush();
bbs.writeTo(response.getOutputStream());
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubs
Intermittent ClassNotFoundException in Jasper EL evaluation
Hi,
We recently upgraded Tomcat from version 7 to version 8 (8.0.32 to be precise),
and we immediately noticed a deterioration in the performance. Page load time
increased from about 500ms to 2500-5000 ms.
One thing we noticed when we looked at some thread dumps, is that quite often a
ClassNotFoundException can be seen. I found that a bit interesting, because it
didn't correspond to any ClassNotFoundException in the log file. However, when
troubleshooting this I noticed that the exception is caught and ignored.
Here is an example stacktrace from one thread dump:
"http-apr-8080-exec-33" Id=282 in RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
- locked java.lang.ClassNotFoundException@26bef633
at java.lang.Throwable.(Throwable.java:287)
at java.lang.Exception.(Exception.java:84)
at
java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
at java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked java.lang.Object@2ca91dd5
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked java.lang.Object@64a0e12a
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked java.lang.Object@1b5f6952
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:344)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
- locked org.apache.catalina.loader.WebappClassLoader@254b720a
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167)
at javax.el.ImportHandler.findClass(ImportHandler.java:195)
at javax.el.ImportHandler.resolveClass(ImportHandler.java:164)
at
javax.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:62)
at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:110)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:80)
at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:46)
at org.apache.el.parser.AstNot.getValue(AstNot.java:43)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:943)
at
org.apache.jsp.template.framework.common.elements.sectionText.sectionText_jsp._jspx_meth_c_005fif_005f3(sectionText_jsp.java:460)
Here is the code on line 460 in sectionText_jsp.java:
_jspx_th_c_005fif_005f3.setTest(((java.lang.Boolean)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${not empty
leadtext}", boolean.class, (javax.servlet.jsp.PageContext)_jspx_page_context,
null)).booleanValue());
And here is the corresponding line in sectionText.jsp:
I cannot for the life of me understand how this simple EL expression can result
in a ClassNotFoundException.
Also, this problem doesn't occur just with this specific jsp file. In fact, it
seems to be a different jsp file involved each time. And it doesn't happen
every time. The fact is that in order for me to recreate the problem in my
local environment, I had to perform quite a few page requests in the browser,
and still it only happened once in a while (with different jsp file each time).
So it is very intermittent, and seems to be something happening deep down in
the core of Tomcat itself. I'm not claiming it is a Tomcat bug, it could very
well be some erroneous configuration that we are using. But the error doesn't
really seem to be related to our code base, or our third party jars.
Has anyone seen this problem before? What could be the cause of it?
Regards
/Jimi
Re: NullPointerException in MemoryRealm after upgrading to Tomcat 8.0.32 from 7.0.26
Chris,
Thanks for the quick and informative response.
On Wed, Mar 9, 2016 at 7:26 AM, Christopher Schultz
wrote:
>
>> For authentication our configuration is using a MemoryRealm with
>> digest="SHA". We are storing usernames and passwords in a
>> tomcat-users.xml file. We are using a jaas.config which specifies to
>> use a org.apache.catalina.realm.JAASMemoryLoginModule. We have our
>> own implementation of a CallbackModule.
>
> I must admit I'm not sure how the JAAS configuration fits into all this
> (I simply have no JAAS experience). But I suspect that since
> JAASMemoryLoginRealm extends RealmBase, it needs to be configured similarly.
>
> The you have in server.xml looks to be configured correctly, but
> I'm not sure it's being used if JAAS is in play. I wouldn't be surprised
> if JAAS is creating a separate instance of the JAASMemoryLoginRealm
> (which is a MemoryRealm) and never setting any of those properties.
>
I was wondering myself how those configurations interacted, if at all.
It does appear as if something like what you're describing is
happening. That makes me wonder if configuring Realm in server.xml is
necessary at all when JAAS is taking the reigns.
> It looks like the best way to set those properties is via the "options"
> for the realm:
>
>>> jaas.config:
>>> /** JAAS Login Configuration for the Application **/
>>>
>>> JAASTomcat {
>>>org.apache.catalina.realm.JAASMemoryLoginModule required debug=true;
>>> };
>
> Instead of simply "debug=true" for the options, we might want to add
> "digest=SHA" and then handle it in the initializer for JAASMemoryLoginRealm.
>
> I think the reason that this works in the older code is that the default
> algorithm of SHA is built-into the MemoryRealm and doesn't require the
> new CredentialHandler stuff. The new method for creating a
> CredentialHandler without actually specifying one (i.e. digest="SHA")
> requires that the "digest" actually be set to something. Since that's
> not happening, you get an NPE.
>
> Since you are willing to build your Tomcat from source, can I give you a
> patch to test?
>
> This is definitely a bug, please file it in Bugzilla if you wouldn't mind:
> https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
>
For what it's worth, that analysis & approach to fixing seem
reasonable to me. Yes I'll be glad to file a bug report and test a
patch.
Thanks,
Jason
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mapping servlet to non English url pattern
Yuval, Notes are inline (I hope). This is quickly becoming a NetBeans question. On 3/9/2016 1:38 AM, Yuval Schwartz wrote: > Thanks Mark, follow up questions below: > > On Wed, Mar 9, 2016 at 1:26 AM, Mark Eggers > wrote: > >> Yuval, >> >> On 3/8/2016 2:35 PM, Yuval Schwartz wrote: >>> On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: >>> On 08/03/2016 20:20, Christopher Schultz wrote: > Yuval, > > On 3/8/16 12:38 PM, Yuval Schwartz wrote: >> Hello Christopher, thanks, responses below. > >> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: > >> Yuval, > >> On 3/8/16 3:14 AM, Yuval Schwartz wrote: > Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > > Hello, > > I want to map my servlet to a Hebrew url pattern. > >> Hmm. > > I tried placing the hebrew url pattern both in the > "@webservlet" annotation (urlpatterns attribute) and in the > the web.xml file. In both cases it doesn't work, it's as if > there's nothing mapped to the url specified. > > I though to specify the URIEncoding parameter of the > connector but saw that this defaults to "utf-8" in tomcat 8. > >> Yes, it does. > >> So you are trying to set the url-pattern for a servlet mapping? > >> When you do it -- either using @WebServlet or -- >> can you connect via JMX to observe the pattern that's been read >> into the configuration? First, I'd want to make sure that the >> Hebrew characters haven't been destroyed by the loading process of >> the XML file or by the compiler, or even by Tomcat. > > >>> Can you give me some direction on how I would do this? Maybe a >>> little more detail on jmx? There could be encoding/decoding going >>> on in the browser (firefox) and in all the elements you mentioned >>> on the server side. Any way to see the final String that the >>> server is using to match the Url pattern? > > Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > the configuration through it. > > Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > that contains a JMX client... both jconsole and VisualVM require that > you go to the "plug-ins" configuration and install an > easy-to-find-and-install plug-in for JMX) on the same machine (it's > easiest this way). > > (I just checked, and VisualVM calls the plug-in > "VisualVM-MBeans".)visualvisual > > Then, connect to the Tomcat instance and go to the BMeans tab. > > You'll find your servlet under >> /Catalina/Servlet/host/context/[servlet]. > .. > > > Aw, crap. The mappings themselves aren't actually published via JMX. >> Hmm Yes they are. You need to look at the operations. findMappings() will list them. >>> >>> I did this and it worked: >>> The english patterns show up fine, as expected. >>> The hebrew pattern shows up as a bunch of question marks (eg: >>> -?-) >>> The URLEncoded pattern shows up as wierd symbols (eg: diamond shape, tm >>> symbol). >>> >>> Could this be something in my IDE (Netbeans) settings? The logs for >>> example, display hebrew characters as question marks. Although my project >>> encoding is set as UTF-8. >>> >>> Thanks. >>> >>> >>> Mark >> >> Are you developing on Windows? (ah, you are) >> >> If so, could you check how you launch NetBeans? My netbeans.conf file >> contains this on the netbeans_default_options line: >> >> -J-Dfile.encoding=UTF-8 >> > > I tried this, still doesn't fix the issue (Although a change is noticed: > going to help-->about under "system" text changes from "cp1252" to "UTF-8"). > Good, the change did take. If you're working with an existing project, you may have to change the encoding on that project as well. Go to the Properties panel by right-mouse clicking on the project, and selecting Properties (should be at the bottom, at least it is on NetBeans 8.1). On the Sources panel at the bottom, make sure that the encoding is UTF-8. Note that for existing projects you will probably have to change this. Also note that for existing files, you'll probably have to do the following: 1. Delete your Hebrew 2. Outside of NetBeans change that file to UTF-8 3. Open in NetBeans 4. Add the Hebrew I know, it's messy, but again NetBeans does not have a plugin to do this internally. > >> >> Also, if you're using Maven with NetBeans, UTF-8 has to be set there as >> well. My projects contain the following in pom.xml: >> >> >> UTF-8 >> >> >> > > I don't think I use Maven for this. I use the default build process (for my > development environment) ie: I right click the project and click "run". For > my production I build with "gulp". I don't know anything about gulp and how it handles UTF-8 on a Windows platform
Destroy type=Service
Hello, my question is, if possible destroy an object type = Service ?. In my current deployment I have two domains: Catalina and app_domain. I want to delete all app_domain. Thanks
Re: Performance regression from 7 to 8
Christopher, thanks for this information, but Tullio said that his problem only occurs with the NIO connector (it seems weird and I don't have sufficient knowledge on how it is coded in Tomcat anyway). The post was already quite long before I suggested him to try both connectors to identify a possible problem there. I'm just being pragmatic here. 2016-03-09 16:41 GMT+01:00 Christopher Schultz : > Aurélien, > > On 3/9/16 8:50 AM, Aurélien Terrestris wrote: > > The doc ( > > > http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#NIO2_specific_configuration > > ) doesn't say which one is the best, but we may think that the > non-blocking > > will work better under heavy load. > > NIO2 is newer and has had less testing in the wild. Between the two I'd > stick to NIO. > > > If not servicing hundreds of clients at the same moment, I would use the > > blocking connector ( http11.Http11Protocol ) > > Note that the blocking connector doesn't work well with asynchronous > protocols like websocket, etc. It is being removed from Tomcat in Tomcat > 9. (RIP BIO) > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
disable Set-Cookie http-only in tomcat 8
Hi I was trying to disable httponly in the setcookie header from tomcat reponse , can some one let me know how to disable it i have tried these 2 but didn't help me 1.) web.xml false 2.) context.xml useHttpOnly="false" curl -I http://localhost:8801 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=7A54CAEC2733B3AB015ED09F9A68C72A; Path=/; *HttpOnly* Content-Type: text/html;charset=ISO-8859-1 Content-Length: 305 Date: Wed, 09 Mar 2016 15:41:48 GMT *Server version: Apache Tomcat/8.0.30Server built: Dec 1 2015 22:30:46 UTC* Server number: 8.0.30.0 OS Name:Linux OS Version: 3.10.0-229.el7.x86_64 Architecture: amd64 JVM Version:1.8.0_73-b02 JVM Vendor: Oracle Corporation
Re: Performance regression from 7 to 8
Aurélien, On 3/9/16 8:50 AM, Aurélien Terrestris wrote: > The doc ( > http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#NIO2_specific_configuration > ) doesn't say which one is the best, but we may think that the non-blocking > will work better under heavy load. NIO2 is newer and has had less testing in the wild. Between the two I'd stick to NIO. > If not servicing hundreds of clients at the same moment, I would use the > blocking connector ( http11.Http11Protocol ) Note that the blocking connector doesn't work well with asynchronous protocols like websocket, etc. It is being removed from Tomcat in Tomcat 9. (RIP BIO) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mapping servlet to non English url pattern
Yuval,
On 3/8/16 4:04 PM, Yuval Schwartz wrote:
> @WebServlet(name="SomeServlet", urlPatterns={"/help/why-no-work",
> "/iw/help/למה-לא-עובד",
> "/iw/help/%D7%9C%D7%9E%D7%94-%D7%9C%D7%90-%D7%A2%D7%95%D7%91%D7%93"}
> (the last pattern is the same as the second to last, just encoded)
I think that last pattern will not be useful, because Tomcat should be
doing the encoding internally. For example, if you wanted to map a
servlet to "/foo bar" you wouldn't have to URL-encode it like /foo%20bar
in the XML file. But I haven't actually tried it.
(from your other post):
On 3/8/16 5:35 PM, Yuval Schwartz wrote:
> I did this and it worked:
> The english patterns show up fine, as expected.
> The hebrew pattern shows up as a bunch of question marks (eg:
> -?-)
> The URLEncoded pattern shows up as wierd symbols (eg: diamond shape,
> tm symbol).
Hmm, that could certainly be a problem with the tool itself (Netbeans?).
Can you try running with jconsole just to have a (potentially) clean
environment?
The encoded pattern showing up as weird symbols sounds .. odd as well.
Actually, everything about this sounds weird.
On 3/9/16 4:38 AM, Yuval Schwartz wrote:
> Are you suggesting I convert all of my source files to UTF-8? Will
> all new files that are created now be in UTF-8 at least? Because I
> just created a new servlet for testing purposes (after the
> -J-Dfile.encoding property was added) and hebrew urls still aren't
> found.
You definitely don't need to convert your files to UTF-8, but you might
instead want to use the encoding-proof Unicode escapes instead of the
raw Hebrew in your source files.
You can use native2ascii to do this for you:
input.txt
/iw/help/למה-לא-עובד
$ native2ascii -encoding utf8 input.txt
/iw/help/\u05dc\u05de\u05d4-\u05dc\u05d0-\u05e2\u05d5\u05d1\u05d3
So those are the \u Unicode escapes that you should use in your code.
Try using those and rebuilding to see if it improves anything.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Harish, On 3/8/16 5:47 PM, Harish Krishnan wrote: > Thanks Chris for the reply. > Looks like my understanding of the fix is incorrect. > I assumed (my bad) that, with the fix for this CVE in place (tomcat > 7.0.68) + setting the additional context attribute > (mapperContextRootRedirectEnabled="false"), all the redirects for that > webapp where context attribute was set, will completely be disabled. > You mentioned that only "protected directories" inside the deployed web > application is covered in this CVE fix. > Can you please help me understand what this protected directories are & how > to configure this in tomcat ? A "protected directory" is one that has a in web.xml. That's not a spec-defined term... just one we've been using because it captures the meaning with fewer words. As for the redirects you are seeing that "expose" the availability of a particular web application, those are essentially impossible to prevent, and not considered a part of the CVE. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NullPointerException in MemoryRealm after upgrading to Tomcat 8.0.32 from 7.0.26
Jason,
On 3/8/16 8:44 PM, Jason Overland wrote:
> Okay, so I checked out Tomcat 8.0.32 from source control. I then
> reverted MemoryRealm's authenticate method to how it was in 7.0.26 and
> built Tomcat and now my authentication works. This of course is not a
> solution, but it obviates most of my other questions. I guess the
> important question is: how do I set the CredentialHandler on the
> MemoryRealm?
The way you are setting the CredentialHandler is correct:
>>
>> > className="org.apache.catalina.realm.MessageDigestCredentialHandler"/>
>>
You actually don't need to specify the CredentialHandler if you specify
the "digest" attribute, since Tomcat will synthesize a
MessageDigestCredentialHandler for you and use the "digest" as the
"algorithm". But it doesn't hurt to do what you have done.
> For authentication our configuration is using a MemoryRealm with
> digest="SHA". We are storing usernames and passwords in a
> tomcat-users.xml file. We are using a jaas.config which specifies to
> use a org.apache.catalina.realm.JAASMemoryLoginModule. We have our
> own implementation of a CallbackModule.
I must admit I'm not sure how the JAAS configuration fits into all this
(I simply have no JAAS experience). But I suspect that since
JAASMemoryLoginRealm extends RealmBase, it needs to be configured similarly.
The you have in server.xml looks to be configured correctly, but
I'm not sure it's being used if JAAS is in play. I wouldn't be surprised
if JAAS is creating a separate instance of the JAASMemoryLoginRealm
(which is a MemoryRealm) and never setting any of those properties.
It looks like the best way to set those properties is via the "options"
for the realm:
>> jaas.config:
>> /** JAAS Login Configuration for the Application **/
>>
>> JAASTomcat {
>>org.apache.catalina.realm.JAASMemoryLoginModule required debug=true;
>> };
Instead of simply "debug=true" for the options, we might want to add
"digest=SHA" and then handle it in the initializer for JAASMemoryLoginRealm.
I think the reason that this works in the older code is that the default
algorithm of SHA is built-into the MemoryRealm and doesn't require the
new CredentialHandler stuff. The new method for creating a
CredentialHandler without actually specifying one (i.e. digest="SHA")
requires that the "digest" actually be set to something. Since that's
not happening, you get an NPE.
Since you are willing to build your Tomcat from source, can I give you a
patch to test?
This is definitely a bug, please file it in Bugzilla if you wouldn't mind:
https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance regression from 7 to 8
The doc ( http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#NIO2_specific_configuration ) doesn't say which one is the best, but we may think that the non-blocking will work better under heavy load. If not servicing hundreds of clients at the same moment, I would use the blocking connector ( http11.Http11Protocol ) regards 2016-03-09 10:12 GMT+01:00 Tullio Bettinazzi : > I tested with http11.Http11Protocol, http11.Http11NioProtocol and > http11.Http11Nio2Protocol and the problem reproduces only with > http11.Http11NioProtocol. > It seems to be a bug of the Nio protocol. > It's better to use Nio2 or standard ? What's the difference ? > Tks > Tullio > > > > Date: Mon, 7 Mar 2016 16:26:24 +0100 > > Subject: Re: Performance regression from 7 to 8 > > From: aterrest...@gmail.com > > To: users@tomcat.apache.org > > > > Tullio, > > > > as suggested before by Felix, maybe you should try different connector > > configurations (defaults for HTTP connector are different between T7 > > (blocking) and T8 (non-blocking)) and see if this changes anything. > > > > For example in the server.xml file : > > > > > protocol="org.apache.coyote.http11.Http11Protocol" address="YOURSERVER" > >connectionTimeout="2" > >disableUploadTimeout="false" > >connectionUploadTimeout="360" > >redirectPort="8843" /> > > > > and > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > address="YOURSERVER" > >connectionTimeout="2" > >disableUploadTimeout="false" > >connectionUploadTimeout="360" > >redirectPort="8843" /> > > > > > > Your code is simple, only buffering and writing to an OutputStream. Don't > > know how, but I believe that only the buffering can introduce some delay. > > > > best regards > > > > > > > > > > > > > > 2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi : > > > > > As I already explained is not a reproductable problem. > > > I tested the testcase in my environment and I reproduced the problem on > > > some clients but not on all clients : the same clients where I noticed > the > > > problem in the real application. > > > I'm not able to understand what's the relevant difference among them > (not > > > OS version, not network, not browser). > > > The problem disappears using tomcat 7. > > > Tks > > > Tullio > > > > > > > Subject: Re: Performance regression from 7 to 8 > > > > To: users@tomcat.apache.org > > > > From: ma...@apache.org > > > > Date: Mon, 7 Mar 2016 11:52:40 + > > > > > > > > On 06/03/2016 08:45, Tullio Bettinazzi wrote: > > > > > I tested with 8.20 and 8.32 > > > > > With nothing changed I meant simply that results didn't change. > > > > > > > > I can't repeat the problem you are describing with your provided test > > > case. > > > > > > > > I ran: > > > > - ab -k -n 1000 -c 1 localhost:8080/user002/Test > > > > - latest 8.0.x code > > > > - your test case with and without setting the content length (as an > > > > HTTP/1.0 client ab needs the content length to use keep-alive with > > > > large response bodies > > > > > > > > I saw average response times of 6ms with a maximum of 9ms. > > > > The content length header made no difference (apart from keep-alive > > > > being used as expected). > > > > > > > > If the problem you are describing was widespread I'd expect to see > other > > > > users reporting this on the mailing list. > > > > > > > > Given that: > > > > - I can't repeat this > > > > - Other users aren't reporting it > > > > - Only you are seeing the issue > > > > > > > > this looks like an issue with your environment rather than with > Tomcat. > > > > I'd recommend using tools like Wireshark and YourKit to find out > exactly > > > > what is going on. > > > > > > > > Mark > > > > > > > > > > > > > Tks > > > > > Tullio > > > > > > > > > >> Subject: Re: Performance regression from 7 to 8 > > > > >> To: users@tomcat.apache.org > > > > >> From: ma...@apache.org > > > > >> Date: Sat, 5 Mar 2016 18:40:36 + > > > > >> > > > > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote: > > > > >>> Done and nothing changed. > > > > >> > > > > >> What has changed is that you have now provided a test case that > > > someone > > > > >> else can run easily and confirm, or not, your findings. > > > > >> > > > > >>> Any suggestion ? > > > > >> > > > > >> Before anyone spends time looking at this the other question I > don't > > > see > > > > >> answered in this thread is "Exactly which Tomcat 8 version were > you > > > > >> testing?". If it isn't the the latest then you'll need to retest > to > > > > >> confirm the issue hasn't already been fixed. > > > > >> > > > > >> Mark > > > > >> > > > > >>> Here the code. > > > > >>> > > > > >>> package axioma.rubik.engine.web.servlet; > > > > >>> > > > > >>> import java.io.*; > > > > >>> import javax.servlet.ServletException; > > > > >>> import javax.servlet.annotation.WebServlet; > > > > >>> import javax.
Re: Mapping servlet to non English url pattern
Thanks Mark, follow up questions below: On Wed, Mar 9, 2016 at 1:26 AM, Mark Eggers wrote: > Yuval, > > On 3/8/2016 2:35 PM, Yuval Schwartz wrote: > > On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: > > > >> On 08/03/2016 20:20, Christopher Schultz wrote: > >>> Yuval, > >>> > >>> On 3/8/16 12:38 PM, Yuval Schwartz wrote: > Hello Christopher, thanks, responses below. > >>> > On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >>> > Yuval, > >>> > On 3/8/16 3:14 AM, Yuval Schwartz wrote: > >>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > >>> > >>> Hello, > >>> > >>> I want to map my servlet to a Hebrew url pattern. > >>> > Hmm. > >>> > >>> I tried placing the hebrew url pattern both in the > >>> "@webservlet" annotation (urlpatterns attribute) and in the > >>> the web.xml file. In both cases it doesn't work, it's as if > >>> there's nothing mapped to the url specified. > >>> > >>> I though to specify the URIEncoding parameter of the > >>> connector but saw that this defaults to "utf-8" in tomcat 8. > >>> > Yes, it does. > >>> > So you are trying to set the url-pattern for a servlet mapping? > >>> > When you do it -- either using @WebServlet or -- > can you connect via JMX to observe the pattern that's been read > into the configuration? First, I'd want to make sure that the > Hebrew characters haven't been destroyed by the loading process of > the XML file or by the compiler, or even by Tomcat. > >>> > >>> > > Can you give me some direction on how I would do this? Maybe a > > little more detail on jmx? There could be encoding/decoding going > > on in the browser (firefox) and in all the elements you mentioned > > on the server side. Any way to see the final String that the > > server is using to match the Url pattern? > >>> > >>> Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > >>> the configuration through it. > >>> > >>> Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > >>> that contains a JMX client... both jconsole and VisualVM require that > >>> you go to the "plug-ins" configuration and install an > >>> easy-to-find-and-install plug-in for JMX) on the same machine (it's > >>> easiest this way). > >>> > >>> (I just checked, and VisualVM calls the plug-in > >>> "VisualVM-MBeans".)visualvisual > >>> > >>> Then, connect to the Tomcat instance and go to the BMeans tab. > >>> > >>> You'll find your servlet under > /Catalina/Servlet/host/context/[servlet]. > >>> .. > >>> > >>> > >>> Aw, crap. The mappings themselves aren't actually published via JMX. > Hmm > >> > >> Yes they are. > >> > >> You need to look at the operations. findMappings() will list them. > >> > > > > I did this and it worked: > > The english patterns show up fine, as expected. > > The hebrew pattern shows up as a bunch of question marks (eg: > > -?-) > > The URLEncoded pattern shows up as wierd symbols (eg: diamond shape, tm > > symbol). > > > > Could this be something in my IDE (Netbeans) settings? The logs for > > example, display hebrew characters as question marks. Although my project > > encoding is set as UTF-8. > > > > Thanks. > > > > > > > >> > >> Mark > > Are you developing on Windows? (ah, you are) > > If so, could you check how you launch NetBeans? My netbeans.conf file > contains this on the netbeans_default_options line: > > -J-Dfile.encoding=UTF-8 > I tried this, still doesn't fix the issue (Although a change is noticed: going to help-->about under "system" text changes from "cp1252" to "UTF-8"). > > Also, if you're using Maven with NetBeans, UTF-8 has to be set there as > well. My projects contain the following in pom.xml: > > > UTF-8 > > > I don't think I use Maven for this. I use the default build process (for my development environment) ie: I right click the project and click "run". For my production I build with "gulp". > > If you have cygwin installed on Windows, you can use the following: > > file -bi [filename] > Which file am I supposed to do this for? > > will tell you the encoding and mime-type. > > iconv will help you convert from us-ascii to UTF-8. The syntax is: > > iconv -f [from-encoding] -t [to-encoding] [input-file] > output-file > Are you suggesting I convert all of my source files to UTF-8? Will all new files that are created now be in UTF-8 at least? Because I just created a new servlet for testing purposes (after the -J-Dfile.encoding property was added) and hebrew urls still aren't found. > > I suspect there are native Windows tools to do this, but I'd have to > wander about and find them. > > Notepad will tell you when you open a file what encoding the file is. > You could then do a "save as" and select the correct encoding. > > Sadly, NetBeans does not have a plugin to do this. > > . . . just my two cents > Thanks. > /mde/ > >
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Hi Harish, 2016-03-09 0:47 GMT+02:00 Harish Krishnan : > > Thanks Chris for the reply. > Looks like my understanding of the fix is incorrect. > I assumed (my bad) that, with the fix for this CVE in place (tomcat > 7.0.68) + setting the additional context attribute > (mapperContextRootRedirectEnabled="false"), all the redirects for that > webapp where context attribute was set, will completely be disabled. > You mentioned that only "protected directories" inside the deployed web > application is covered in this CVE fix. > Can you please help me understand what this protected directories are & how > to configure this in tomcat ? As Mark already pointed, look at the web.xml of Manager application -> security constraints sections. Also you may find the following link [1] useful. Regards, Violeta [1] https://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html > > regards > Harish Krishnan > > On Tue, Mar 8, 2016 at 7:59 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Harish, > > > > On 3/7/16 6:02 PM, Harish Krishnan wrote: > > > Unfortunately, i still could not verify this vulnerability as it > > > still appears not fixed & my requests get redirected. > > > > What makes you think that the requests should not be redirected? > > > > > Instead of using the manager webapp that comes default in tomcat, > > > we created a sample webapp with the following security constraint > > > - > > > hello.html > > > > > > sercure-hello > > > /* > > > > > > NONE > > > > > > > > > Accessing http://localhost:8080/a (which exist) gets redirected to > > > http://localhost:8080/a/ & then get 404. Accessing > > > http://localhost:8080/b (does not exist) simply gets 404. > > > > Where did you deploy this sample web application? > > > > > I have set the context attribute (mapperContextRootRedirectEnabled) > > > as well - > > antiResourceLocking="false" privileged="true"> > > > > > > My question simply boils down to, What additional setting i need to > > > do for the above redirect to NOT happen. > > > > Which redirect? A redirect for a protected directory inside of a > > deployed web application (which is what this CVE covers) or the > > redirect for a deployed web application (which is not what this CVE > > covers)? > > > > - -chris > > -BEGIN PGP SIGNATURE- > > Comment: GPGTools - http://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlbe9twACgkQ9CaO5/Lv0PBaqQCeMMYqM8+hPnekw1NM8I5NNa0J > > uaQAn2Kp35FIKikIFfZdlao4Un1NCNGe > > =/uiq > > -END PGP SIGNATURE- > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > >
RE: Performance regression from 7 to 8
I tested with http11.Http11Protocol, http11.Http11NioProtocol and
http11.Http11Nio2Protocol and the problem reproduces only with
http11.Http11NioProtocol.
It seems to be a bug of the Nio protocol.
It's better to use Nio2 or standard ? What's the difference ?
Tks
Tullio
> Date: Mon, 7 Mar 2016 16:26:24 +0100
> Subject: Re: Performance regression from 7 to 8
> From: aterrest...@gmail.com
> To: users@tomcat.apache.org
>
> Tullio,
>
> as suggested before by Felix, maybe you should try different connector
> configurations (defaults for HTTP connector are different between T7
> (blocking) and T8 (non-blocking)) and see if this changes anything.
>
> For example in the server.xml file :
>
> protocol="org.apache.coyote.http11.Http11Protocol" address="YOURSERVER"
>connectionTimeout="2"
>disableUploadTimeout="false"
>connectionUploadTimeout="360"
>redirectPort="8843" />
>
> and
>
> protocol="org.apache.coyote.http11.Http11NioProtocol" address="YOURSERVER"
>connectionTimeout="2"
>disableUploadTimeout="false"
>connectionUploadTimeout="360"
>redirectPort="8843" />
>
>
> Your code is simple, only buffering and writing to an OutputStream. Don't
> know how, but I believe that only the buffering can introduce some delay.
>
> best regards
>
>
>
>
>
>
> 2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi :
>
> > As I already explained is not a reproductable problem.
> > I tested the testcase in my environment and I reproduced the problem on
> > some clients but not on all clients : the same clients where I noticed the
> > problem in the real application.
> > I'm not able to understand what's the relevant difference among them (not
> > OS version, not network, not browser).
> > The problem disappears using tomcat 7.
> > Tks
> > Tullio
> >
> > > Subject: Re: Performance regression from 7 to 8
> > > To: users@tomcat.apache.org
> > > From: ma...@apache.org
> > > Date: Mon, 7 Mar 2016 11:52:40 +
> > >
> > > On 06/03/2016 08:45, Tullio Bettinazzi wrote:
> > > > I tested with 8.20 and 8.32
> > > > With nothing changed I meant simply that results didn't change.
> > >
> > > I can't repeat the problem you are describing with your provided test
> > case.
> > >
> > > I ran:
> > > - ab -k -n 1000 -c 1 localhost:8080/user002/Test
> > > - latest 8.0.x code
> > > - your test case with and without setting the content length (as an
> > > HTTP/1.0 client ab needs the content length to use keep-alive with
> > > large response bodies
> > >
> > > I saw average response times of 6ms with a maximum of 9ms.
> > > The content length header made no difference (apart from keep-alive
> > > being used as expected).
> > >
> > > If the problem you are describing was widespread I'd expect to see other
> > > users reporting this on the mailing list.
> > >
> > > Given that:
> > > - I can't repeat this
> > > - Other users aren't reporting it
> > > - Only you are seeing the issue
> > >
> > > this looks like an issue with your environment rather than with Tomcat.
> > > I'd recommend using tools like Wireshark and YourKit to find out exactly
> > > what is going on.
> > >
> > > Mark
> > >
> > >
> > > > Tks
> > > > Tullio
> > > >
> > > >> Subject: Re: Performance regression from 7 to 8
> > > >> To: users@tomcat.apache.org
> > > >> From: ma...@apache.org
> > > >> Date: Sat, 5 Mar 2016 18:40:36 +
> > > >>
> > > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote:
> > > >>> Done and nothing changed.
> > > >>
> > > >> What has changed is that you have now provided a test case that
> > someone
> > > >> else can run easily and confirm, or not, your findings.
> > > >>
> > > >>> Any suggestion ?
> > > >>
> > > >> Before anyone spends time looking at this the other question I don't
> > see
> > > >> answered in this thread is "Exactly which Tomcat 8 version were you
> > > >> testing?". If it isn't the the latest then you'll need to retest to
> > > >> confirm the issue hasn't already been fixed.
> > > >>
> > > >> Mark
> > > >>
> > > >>> Here the code.
> > > >>>
> > > >>> package axioma.rubik.engine.web.servlet;
> > > >>>
> > > >>> import java.io.*;
> > > >>> import javax.servlet.ServletException;
> > > >>> import javax.servlet.annotation.WebServlet;
> > > >>> import javax.servlet.http.*;
> > > >>>
> > > >>> @WebServlet(name="Test8", description="Direct update of data",
> > urlPatterns={"/Test8"})
> > > >>> public class Test8Servlet extends HttpServlet {
> > > >>>
> > > >>> private static final long serialVersionUID = 1L;
> > > >>>
> > > >>> @Override
> > > >>> protected void doGet(HttpServletRequest request,
> > HttpServletResponse response) throws ServletException, IOException {
> > > >>> try {
> > > >>> fai(response);
> > > >>> } catch (Exception ex) {
> > > >>> ex.printStackTrace();
> > > >>> }
> > > >>> }
> > > >>>
> > > >>> public vo
