Re: Performance regression from 7 to 8

2016-03-09 Thread Christopher Schultz
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

2016-03-09 Thread Violeta Georgieva
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

2016-03-09 Thread Mark Thomas
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

2016-03-09 Thread Yuval Schwartz
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 

Re: Mapping servlet to non English url pattern

2016-03-09 Thread Yuval Schwartz
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

2016-03-09 Thread Felix Schumacher

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, 

Intermittent ClassNotFoundException in Jasper EL evaluation

2016-03-09 Thread jimi.hullegard
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

2016-03-09 Thread Jason Overland
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

2016-03-09 Thread Mark Eggers
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 

Destroy type=Service‏

2016-03-09 Thread Roque Alexander Lozano Lozano
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

2016-03-09 Thread Aurélien Terrestris
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

2016-03-09 Thread 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"


  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

2016-03-09 Thread 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



Re: Mapping servlet to non English url pattern

2016-03-09 Thread Christopher Schultz
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

2016-03-09 Thread Christopher Schultz
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

2016-03-09 Thread Christopher Schultz
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

2016-03-09 Thread Aurélien Terrestris
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 

Re: Mapping servlet to non English url pattern

2016-03-09 Thread Yuval Schwartz
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.
>
> . . . 

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

2016-03-09 Thread Violeta Georgieva
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

2016-03-09 Thread 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.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();
> > > >>> }
> > > >>> }
> > > >>>
>