RE: Performance regression from 7 to 8
I tested with 8.20 and 8.32
With nothing changed I meant simply that results didn't change.
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
>
RE: Performance regression from 7 to 8
What do you mean with :
Have you tried switching the connectors on the tomcat side?
???
Tks
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: felix.schumac...@internetallee.de
> Date: Sat, 5 Mar 2016 14:00:11 +0100
>
> Am 05.03.2016 um 12:34 schrieb Tullio Bettinazzi:
> > This is not a memory problem because, otherwise, I'll have the same problem
> > on all client systems.
> > It's a communication related problem between server and clients but not
> > strictly a network problem because, otherwise, two clients, connected to
> > the same cable would perform in the same way.
> If it is stable slow on one client, then you could take threaddumps on
> the tomcat side and look what it is doing. On the network side, you
> could look at a tcpdump.
>
> Have you tried switching the connectors on the tomcat side?
>
> Felix
> > Tks
> > Tullio
> >
> >> Subject: Re: Performance regression from 7 to 8
> >> To: users@tomcat.apache.org
> >> From: felix.schumac...@internetallee.de
> >> Date: Sat, 5 Mar 2016 11:13:58 +0100
> >>
> >> Am 04.03.2016 um 14:19 schrieb Tullio Bettinazzi:
> >>> Done and nothing changed.
> >>> Any suggestion ?
> >> It could be related to memory usage.
> >>
> >> Tomcat 8 can use more memory than tomcat 7 (See
> >> https://mail-archives.apache.org/mod_mbox/tomcat-users/201602.mbox/%3ccacbju2wmw7mntevb6hwjqdfzsjpmfiuw6k_dn1u0ufh0haj...@mail.gmail.com%3E)
> >>
> >> So try to look at your memory consumption and adjust the limits for the
> >> jvm accordingly. For monitoring, you can enable gc logging, or use
> >> something like jstat, jconsole, jvisualvm, jmc or any other monitoring
> >> tool.
> >>
> >> Mark has worked on the memory issue and lowered consumption for newer
> >> versions. I think they will be in the next release.
> >>
> >> Regards,
> >>Felix
> >>> 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());
> >>> }
> >>> }
> >>>
> Date: Fri, 4 Mar 2016 12:58:02 +0100
> Subject: Re: Performance regression from 7 to 8
> From: r...@apache.org
> To: users@tomcat.apache.org
>
> 2016-03-04 12:42 GMT+01:00 Mark Thomas :
>
> > On 04/03/2016 11:17, Tullio Bettinazzi wrote:
> >> This servlet reproduces the problem perfectly.
> > Getting better but still some room for improvement.
> > - You don't need to implement doPost()
> > - You don't need to call System.gc() (or if you do look there for
> > the problem)
> >
> Yes, it's on every get and will cause a major concurrency issue.
>
>
> > - You do need to remove the use of the ComunicationChannelHttp and
> > Cronometro classes (and if that fixes the problem look there
> > for the root cause)
> > - The try/catch in doGet() should not be necessary either
> >
> Also writing individual bytes is more costly even if there's some
> buffering.
>
> Rémy
>
> > Mark
> >
> >> package axioma.rubik.engine.web.servlet;
> >>
> >> import java.io.*;
> >> import javax.servlet.ServletException;
> >> import javax.servlet.annotation.WebServlet;
> >> import javax.servlet.http.*;
> >> import axioma.rubik.engine.web.ComunicationChannelHttp;
> >> import it.axioma.rubik.engine.Cronometro;
> >>
> >> @WebServlet(name="Test8", description="Direct update of data",
> > urlPatterns={"/Test8"})
> >> public class Test8Servlet extends HttpServlet {
> >>
> >> private static final long serialVersionUID = 1L;
> >>
> >> @Override
> >> protected void doPost(HttpServletRequest request,
> > HttpServletResponse response) throws ServletException, IOException {
> >> this.doGet(request,response);
> >> }
> >>
> >> @Override
> >> p
RE: Performance regression from 7 to 8
Am 6. März 2016 13:07:39 MEZ, schrieb Tullio Bettinazzi :
>What do you mean with :
>Have you tried switching the connectors on the tomcat side?
The http connector has different implementations. See
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
Felix
> ???
>Tks
>
>
>> Subject: Re: Performance regression from 7 to 8
>> To: users@tomcat.apache.org
>> From: felix.schumac...@internetallee.de
>> Date: Sat, 5 Mar 2016 14:00:11 +0100
>>
>> Am 05.03.2016 um 12:34 schrieb Tullio Bettinazzi:
>> > This is not a memory problem because, otherwise, I'll have the same
>problem on all client systems.
>> > It's a communication related problem between server and clients but
>not strictly a network problem because, otherwise, two clients,
>connected to the same cable would perform in the same way.
>> If it is stable slow on one client, then you could take threaddumps
>on
>> the tomcat side and look what it is doing. On the network side, you
>> could look at a tcpdump.
>>
>> Have you tried switching the connectors on the tomcat side?
>>
>> Felix
>> > Tks
>> > Tullio
>> >
>> >> Subject: Re: Performance regression from 7 to 8
>> >> To: users@tomcat.apache.org
>> >> From: felix.schumac...@internetallee.de
>> >> Date: Sat, 5 Mar 2016 11:13:58 +0100
>> >>
>> >> Am 04.03.2016 um 14:19 schrieb Tullio Bettinazzi:
>> >>> Done and nothing changed.
>> >>> Any suggestion ?
>> >> It could be related to memory usage.
>> >>
>> >> Tomcat 8 can use more memory than tomcat 7 (See
>> >>
>https://mail-archives.apache.org/mod_mbox/tomcat-users/201602.mbox/%3ccacbju2wmw7mntevb6hwjqdfzsjpmfiuw6k_dn1u0ufh0haj...@mail.gmail.com%3E)
>> >>
>> >> So try to look at your memory consumption and adjust the limits
>for the
>> >> jvm accordingly. For monitoring, you can enable gc logging, or use
>> >> something like jstat, jconsole, jvisualvm, jmc or any other
>monitoring tool.
>> >>
>> >> Mark has worked on the memory issue and lowered consumption for
>newer
>> >> versions. I think they will be in the next release.
>> >>
>> >> Regards,
>> >>Felix
>> >>> 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());
>> >>> }
>> >>> }
>> >>>
>> Date: Fri, 4 Mar 2016 12:58:02 +0100
>> Subject: Re: Performance regression from 7 to 8
>> From: r...@apache.org
>> To: users@tomcat.apache.org
>>
>> 2016-03-04 12:42 GMT+01:00 Mark Thomas :
>>
>> > On 04/03/2016 11:17, Tullio Bettinazzi wrote:
>> >> This servlet reproduces the problem perfectly.
>> > Getting better but still some room for improvement.
>> > - You don't need to implement doPost()
>> > - You don't need to call System.gc() (or if you do look there
>for
>> > the problem)
>> >
>> Yes, it's on every get and will cause a major concurrency issue.
>>
>>
>> > - You do need to remove the use of the ComunicationChannelHttp
>and
>> > Cronometro classes (and if that fixes the problem look
>there
>> > for the root cause)
>> > - The try/catch in doGet() should not be necessary either
>> >
>> Also writing individual bytes is more costly even if there's
>some buffering.
>>
>> Rémy
>>
>> > Mark
>> >
>> >> package axioma.rubik.engine.web.servlet;
>> >>
>> >> import java.io.*;
>> >> import javax.servlet.ServletException;
>> >> import javax.servlet.annotation.WebServlet;
>> >> import javax.servlet.http.*;
>> >> import axioma.rubik.engine.web.ComunicationChannelHttp;
>> >> import it.axioma.rubik.engine.Cronometro;
>> >>
>> >> @WebServlet(name="Test8", description="Direct update of data",
>> > urlPatterns={"/Test8"})
>> >> public class Test8Servlet extends HttpServlet {
>> >>
>> >> private static final long serialVersionUID = 1L;
>> >>
>> >>>
Warning response header
Tomcat 8_32
Windows 7
Java 8_51
RestEasy 3.0.11.Final
GWT 2.7.0 (Jetty jetty-9.3.5.v20151012)
Servlet code makes a RestEasy call to another servlet (same container) -
second servlet sets the 'Warning' HTTP header on response. Would like to
access that in first servlet but when running in Tomcat, that header is not
included.
Code to get header in first servlet:
Object headers = ((ClientResponseFailure)
e).getResponse().getResponseHeaders().get("Warning");
Also tried: getHeaders(), getStringHeaders(), and getHeaderString().
When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the
above returns a List with one item that contains the warning string. When
remote debugging Tomcat, that call returns null.
Added this to web app xml, and also tried Tomcat conf/web.xml...
CorsFilter
org.apache.catalina.filters.CorsFilter
cors.exposed.headers
Warning
CorsFilter
/*
Also tried cors.allowed.headers.
Any pointers?
Re: Windows Authentication
In response to *George Stanchev*, I tried with Chrome and IE 11, same behavior in both. And yes I tried waffle, but in another webapp. Waffle does not prompt for the credentials. In response to *André Warnier*, I tired that to no avail :( In response to *Felix Schumacher*, It is not a problem with the webapp. I have tried both of what you asked. Tomcat Keytab is authenticated successfully. And KRB debug shows success for the keytab. So here are my additional findings over the weekend. Background - My test AD is virtual. My Domain Controller and client are VMS. 1. *Windows Logon was using NTLM instead of Kerberos* Some article led me to the following assumption : When the browser receives WWW-Authenticate: Negotiate, it asks for the token from the OS Cache. The OS Cache provides it a token that was obtained via NTLM. The Server does not accept that since it specifically wants Kerberos. And hence the browser asks for Credentials again and this time the user is authenticated via Kerberos. And this token is accepted by the Server. 2. *Windows Logon by IP Address uses NTLM* I access the client machine (with tomcat) using RDP via the IP Address. The following question on StackExchange indicates that in such a scenario NTLM is used to logon to the system. See : http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain 3. *Kerberos Event Logging* The next thing I was trying to figure was why Windows logon was using NTLM. The above link suggests that there was no way of forcing LSA to use Kerberos only. So now I am looking at the System events, which might suggest which protocol is being used. Also I enabled Kerberos event logging to see if there were any Kerberos Errors. See : https://support.microsoft.com/en-us/kb/262177 Thanks, Chanchal R. Kariwala Product Engineer Seclore Technology chanchal.kariw...@seclore.com www.seclore.com On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher < felix.schumac...@internetallee.de> wrote: > Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala: > >> I tries what you asked and I have observed the following >> >> 1. Browser sends a request for the resource >> Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response >> Headers >> >> 2. Browser sends a new request with the following in Request Headers >> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg >> >> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in >> Response Headers >> >> 3. At this point the browser shows HTTP Basic Auth form and sends the >> following in Headers >> Authorization: Negotiate >> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge >> value, much much longer than the first one*) >> >> Now the Server replies with HTTP 200 and the following in headers >> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0 >> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly >> >> So yes WIA is failing.. >> Can you help me out with the next step in debugging? >> > You can enable debugging for kerberos in the jvm and you can enable debug > logs for the SpnegoAuthenticator in tomcat to get more information. > > To enable debug log messages in the jvm add > > -Dsun.security.krb5.debug=true > > to CATALINA_OPTS. The log messages will appear in catalina.out and are > quite verbose. > > To enable debug log messages for SpnegoAuthenticator, add > > org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE > > to conf/logging.properties in your CATALINA_BASE directory. > > Regards, > Felix > > >> >> >> >> Thanks, >> Chanchal R. Kariwala >> Product Engineer >> Seclore Technology >> chanchal.kariw...@seclore.com >> www.seclore.com >> >> >> >> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) >> wrote: >> >> On 04.03.2016 07:16, Chanchal Kariwala wrote: >>> >>> I am using Tomcat 8.0.32 and I have followed the guide given at - https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server) - https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w Windows AD Auth is working i.e. when I access the site, I am asked for credentials and when I enter the correct credentials, the restricted resource is displayed. However my question is why the browser is asking for credentials? Why isn't it accessing TGT Cache in the OS to fetch the user's credentials? I have enabled Integrated Windows Auth in IE Settings. I have added the site in Intranet Sites and set "Logon by Current User" in Custom Level setting for Intranet. Hi. >>> >>> The real *key* to debugging such issues, is to use some plugin or add-on >>> to the browser, to enable the capture and visualisation of the HTTP >>> dialog >>> back and forth between the browser and the server. >>> Since you are using IE, I suggest "Fiddler2". >>>
Re: Windows Authentication
The article which suggested that NTLM is being used by Winlogon instead of Kerberos : http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header So the token browser sends on first 401 starts from YHkG... And the second token begins with YIIK1QYG Thanks, Chanchal R. Kariwala Product Engineer Seclore Technology chanchal.kariw...@seclore.com www.seclore.com On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala < chanchal.kariw...@seclore.com> wrote: > In response to *George Stanchev*, > I tried with Chrome and IE 11, same behavior in both. And yes I tried > waffle, but in another webapp. Waffle does not prompt for the credentials. > > In response to *André Warnier*, > I tired that to no avail :( > > In response to *Felix Schumacher*, > It is not a problem with the webapp. I have tried both of what you asked. > Tomcat Keytab is authenticated successfully. And KRB debug > shows success for the keytab. > > So here are my additional findings over the weekend. > Background - My test AD is virtual. My Domain Controller and client are > VMS. > > 1. *Windows Logon was using NTLM instead of Kerberos* > > Some article led me to the following assumption : > > When the browser receives WWW-Authenticate: Negotiate, it asks for the > token from the OS Cache. The OS Cache provides it a token that was obtained > via NTLM. The Server does not accept that since it specifically wants > Kerberos. And hence the browser asks for Credentials again and this time > the user is authenticated via Kerberos. And this token is accepted by the > Server. > > > 2. *Windows Logon by IP Address uses NTLM* > > I access the client machine (with tomcat) using RDP via the IP Address. > The following question on StackExchange indicates that in > such a scenario NTLM is used to logon to the system. > > See : > http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain > > > 3. *Kerberos Event Logging* > > The next thing I was trying to figure was why Windows logon was using > NTLM. The above link suggests that there was no way of forcing > LSA to use Kerberos only. So now I am looking at the System events, which > might suggest which protocol is being used. > > Also I enabled Kerberos event logging to see if there were any Kerberos > Errors. > > See : https://support.microsoft.com/en-us/kb/262177 > > > Thanks, > Chanchal R. Kariwala > Product Engineer > Seclore Technology > chanchal.kariw...@seclore.com > > www.seclore.com > > > > On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher < > felix.schumac...@internetallee.de> wrote: > >> Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala: >> >>> I tries what you asked and I have observed the following >>> >>> 1. Browser sends a request for the resource >>> Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response >>> Headers >>> >>> 2. Browser sends a new request with the following in Request Headers >>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg >>> >>> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in >>> Response Headers >>> >>> 3. At this point the browser shows HTTP Basic Auth form and sends the >>> following in Headers >>> Authorization: Negotiate >>> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge >>> value, much much longer than the first one*) >>> >>> Now the Server replies with HTTP 200 and the following in headers >>> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0 >>> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly >>> >>> So yes WIA is failing.. >>> Can you help me out with the next step in debugging? >>> >> You can enable debugging for kerberos in the jvm and you can enable debug >> logs for the SpnegoAuthenticator in tomcat to get more information. >> >> To enable debug log messages in the jvm add >> >> -Dsun.security.krb5.debug=true >> >> to CATALINA_OPTS. The log messages will appear in catalina.out and are >> quite verbose. >> >> To enable debug log messages for SpnegoAuthenticator, add >> >> org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE >> >> to conf/logging.properties in your CATALINA_BASE directory. >> >> Regards, >> Felix >> >> >>> >>> >>> >>> Thanks, >>> Chanchal R. Kariwala >>> Product Engineer >>> Seclore Technology >>> chanchal.kariw...@seclore.com >>> www.seclore.com >>> >>> >>> >>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) >>> wrote: >>> >>> On 04.03.2016 07:16, Chanchal Kariwala wrote: I am using Tomcat 8.0.32 and I have followed the guide given at > > - > > > https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server) > - > > > https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w > > Windows AD Auth is working i.e. when I access the site, I am asked for > credentials and when I enter the c
