Re: Tomcat 8 Application dispatcherServlet Stats
Hello The "Processing time" metric represents the execution time of StandardWrapperValve#invoke(). This is the execution time of the servlet and filters. This value of "Processing time" is the total time of each request execution time. What is the dispatcherServlet? If dispatcherServlet accept all request as a front controller(like Spring's DispatcherServlet), then this value is the total execution time of all request that the context receive. 2016-01-13 20:19 GMT+09:00 Theo Sweeny : > Hello - at the moment stats can be found for Tomcat 8 web services using > the manager UI /manager/status/all > > Is the "Processing time" metric found under dispatcherServlet [ / ] > subsection, the total time take to serve all requests, including the > response time for each request? > > Regards, > > Theo > Avios Group (AGL) Ltd is a limited company registered in England > (registered number 2260073 and VAT number 512566754) whose registered > address is Astral Towers, Betts Way, London Road, Crawley, West Sussex RH10 > 9XY . Avios Group (AGL) Limited is part of the IAG group of companies This > email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. >
Re: First DB Pool connection returns stale data?
Brian, On 1/11/16 5:14 PM, Tieman,Brian wrote: > I¹ve got a REST service that¹s backed by Hibernate calling MYSQL and using > org.apache.tomcat.jdbc.pool.DataSourceFactory for DB connections. The > connection pool is created with: > >username=³me" password=³my password" > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > name=³jdbc/MyDB" > type="javax.sql.DataSource" > url="jdbc:mysql://my.database.net" > validationQuery="select 1" > validationQueryTimeout="60" > testOnBorrow="true" > testWhileIdle="true" > removeAbandoned="true" > removeAbandonedTimeout="30" > suspectTimeout="15" > logAbandoned="true" > timeBetweenEvictionRunsMillis="5000" > minEvictableIdleTimeMillis="6" > validationInterval="3" > /> Hibernate is not involved in the above configuration. Is that what you were expecting? > It looks like the first record retrieved from the service is being stored > somehow. tomcat-jdbc definitely does not cache records. > I can alter the data retrieved by the first select but I¹ll > occasionally get the initial data back on a subsequent selects. After > much troubleshooting, it feels like the stale data is returned only when > my select is performed with the same connection (from the pool) as the > first select since the service started. I don¹t know how to tell for sure > that the initial connection is the one holding onto old data but the old > data is always the first data I¹ve read and it will be returned seemingly > randomly although the data in the underlying database is correct and we > have no caching turned on in hibernate. What happens if you issue a raw JDBC SELECT from a pooled connection without using hibernate? > My test procedure has been: > > 1) Start service > 2) Read record > 3) Change record > 4) Read record > 5) Repeat 4 > > > If nothing else is hitting the service (no concurrency) I never see stale > data. It¹s only when other clients are hitting the service that I > randomly get stale data returned. The stale data is always the first > record read and is only returned when attempting to read that record again. > > Has anyone ever seen anything like this? Ideas on where to troubleshoot? I've never seen anything like this, but I've never used hibernate. My knee-jerk reaction is that this is Hibernate-related, but you could also be using Hibernate incorrectly. What's the smallest test case you can built that still demonstrates this behavior? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Client TLS 1.2 error for APR
Hi Markt, Sorry, I did not include this since I'm using standard in release (1.1.33). I know of the more recent releases, but I can't just update (production), and in release note's I did not find anything that might help. Thanks, Harrie -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: woensdag 13 januari 2016 20:59 To: Tomcat Users List Subject: Re: Client TLS 1.2 error for APR On 13/01/2016 18:36, Harrie Robins wrote: > Hi! > > I'm running Tomcat 7.0.65 with APR connector over port 443. Tomcat version - tick Connector config - tick Tomcat-Native version ... ? Mark > I'm experiencing > trouble with users that connect with IE11 over SSL. Connecting and > browsing works fine, but sometimes a white screen with this error pops > up. Once they disable TLS 1.2 everything works fine: > > > > This page can't be displayed > > Turn on TLS 1.0, TLS1.1 and TLS 1.2 in Advanced settings and try > connecting to https://sub.example.com again. If this error persists, > contact your site administrator. > > > > Right now I'm using SHA-2 encryption (we moved from SHA-1) with A+ > rating on SSLLabs, without any error's. > > > > Server.xml configuration. Ciphers following latest intermediate from > Mozilla openssl config: > > > > > protocol="org.apache.coyote.http11.Http11AprProtocol" > > connectionTimeout="6000" > > maxThreads="500" > > maxKeepAliveRequests="-1" > > acceptCount="200" > > SSLEnabled="true" > > scheme="https" > > secure="true" > > clientAuth="false" > > enableLookups="false" > > SSLCertificateFile="C:\server\ssl\server.crt" > > SSLCertificateKeyFile="C: \server\ssl\private.key" > > SSLCACertificateFile="C: \server\ssl\intermediate.crt" > > SSLPassword="passw" > > SSLProtocol="all -SSLv2-SSLv3" > > SSLHonorCipherOrder="true" > SSLCipherSuite="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA > 256:EC > DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128 > -GCM-S > HA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:EC > DHE-EC > DSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RS > A-AES2 > 56-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-A > ES256- > SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE > -RSA-A > ES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:A > ES256- > GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMEL > LIA:DE > S-CBC3-SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_1 > 28_CBC > _SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA: > !EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE:!EDH" > > /> > > > > Does anyone have a pointer about what could be wrong with this > configuration? > > > > Kind regards, > > > > Harrie > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error deploying WAR
Chris, On 1/12/2016 10:26 AM, Christopher Schultz wrote: Mark, On 1/12/16 12:03 PM, Mark Thomas wrote: On 12/01/2016 16:40, George Sexton wrote: I'm hitting an error, and I'm not sure how to fix it. The environment is: Check the JARs in WEB-INF/lib for any javax.servlet classes. There should not be any. You might as well check WEB-INF/classes while you are at it. If any JARs have been added to $CATALINA_BASE/lib then check them too. I see these problems when using Eclipse and extracting .class files while Eclipse is trying to figure out something like a new .jar file being added or something that requires a complete rebuild. Thanks. You were right on. In the Eclipse project, there were some kind of strange errors. I googled, did the "right click and select Quick Fix" thing and that got it I'm not really an Eclipse person. I use an editor call SlickEdit (windows and Linux) with ant to build things, so it was kind of new to me. Eclipse, rather than failing to create a .class file, will instead create a .class file that has a static initializer that looks something like this: static { throw new Error("Can't compile class: [errors]"); } So you have a valid .class file but it will bomb every time. Reasonable people can disagree over whether this is good or bad behavior (but I say it's bad). George, the upshot is that you will almost certainly have to re-build your WAR. Try doing a completely clean build if your application and try again with a fresh WAR. -chris OS: Ubuntu Linux Tomcat: 6.0.44 JVM: Sun 1.6.0.22 CATALINA_HOME/CATALINA_BASE configuration The client reports that this system has worked in the past. Their original production system was running 6.0.18 using a distribution specific installation of tomcat, so I made a clean install of tomcat 6.0.44 using downloaded binaries and made a new, minimalist CATALINA_HOME/CATALINA_BASE. I admit, I'm not an expert on Spring, so I'm mystified as to why it's not going. I've searched the internet for relevant things but all I can find are articles that talk about eclipse and adding servlet-api.jar to the compilation path. Help! INFO: Initializing Spring FrameworkServlet 'freightrates' Jan 12, 2016 9:27:17 AM org.apache.catalina.core.ApplicationContext log SEVERE: StandardWrapper.Throwable org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'urlMapping' defined in ServletContext resource [/WEB-INF/freightrates-servlet.xml]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'freightRates' defined in ServletContext resource [/WEB-INF/freightrates-servlet.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.xxx.freight.web.controller.FreightRatesController]: Constructor threw exception; nested exception is java.lang.Error: Unresolved compilation problems: The import javax.servlet.http.HttpServletRequest cannot be resolved The import javax.servlet.http.HttpServletResponse cannot be resolved The method onSubmit(HttpServletRequest, HttpServletResponse, Object, BindException) of type FreightRatesController must override or implement a supertype method HttpServletRequest cannot be resolved to a type HttpServletResponse cannot be resolved to a type HttpServletRequest cannot be resolved to a type HttpServletRequest cannot be resolved to a type HttpServletRequest cannot be resolved to a type The method showForm(HttpServletRequest, HttpServletResponse, BindException, Map) of type FreightRatesController must override or implement a supertype method HttpServletRequest cannot be resolved to a type HttpServletResponse cannot be resolved to a type The method referenceData(HttpServletRequest, Object, Errors) of type FreightRatesController must override or implement a supertype method HttpServletRequest cannot be resolved to a type The method isFormChangeRequest(HttpServletRequest, Object) of type FreightRatesController must override or implement a supertype method HttpServletRequest cannot be resolved to a type The method onFormChange(HttpServletRequest, HttpServletResponse, Object, BindException) of type FreightRatesController must override or implement a supertype method HttpServletRequest cannot be resolved to a type HttpServletResponse cannot be resolved to a type at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) - To unsubscribe, e-mail: users-unsubscr...@tomcat.
Re: Parameter handling on forward
On Wed, Jan 13, 2016 at 12:20 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > All, > For the benefit of the archives: > https://bz.apache.org/bugzilla/show_bug.cgi?id=58836 > > This issue was raised in BZ and will be fixed in Tomcat 8.0.31 as well > as others. See the bug for details. > > Thanks, Mark, for the bug report and the test case. > > -chris > > I'm relieved it was a real bug and not me doing something embarrassingly stupid.
Re: troughput difference
Ok, Sorry for taking so long to answer, we are using this versions in a production enviroment (one server, to just selected users). So we solved our problem, we changed the jsp-api that tomcat uses, we are using the jsp-api 2.2 from glassfish (we are still studying the side effects from that change). After we profile, our thread dumps showed that 60% of the time of the request were spended in tag.service methods. At first we thought that the error was in our code, but we didnt change anything in the jsp's. So after searching for the problem, we find this bug report https://bz.apache.org/bugzilla/show_bug.cgi?id=57583. With the glassfish version we are faster then ever, but we afraid of the side effects this can have. - Mensagem original - De: "Christopher Schultz" Para: "Tomcat Users List" Enviadas: Quinta-feira, 24 de dezembro de 2015 15:28:49 Assunto: Re: troughput difference Aurélien, On 12/24/15 4:17 AM, Aurélien Terrestris wrote: > probably this won't solve your problem but I notice that the random seems > slow : > Creation of SecureRandom instance for session ID generation using > [SHA1PRNG] took [9,870] milliseconds. > > Maybe should you then start by fixing this, it has been discussed many > times on the mailing list ( securerandom.source=file:/dev/./urandom ) Once Tomcat starts up, it should go fairly quickly. I don't know how often SecureRandom re-seeds itself (or even if it does), but you only need entropy during the seeding process. It shouldn't have any effect on the throughput of a few thousand requests. > Maybe are there some tests to do to understand if your Tomcat 6 seems fast > because it uses some caching somewhere, or on the contrary if your Tomcat 8 > is slow because there is a bottleneck. > I would try one scenario with one small HTML page requested thousands of > times, and one very big file requested just 2 or 3 times, and compare > results. > > One thing which could help in understanding, have a look at the status > servlet which gives statistics ( > http://tomcat.apache.org/tomcat-7.0-doc/apr.html ) Rafael, I'm curious: what is your testing procedure? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parameter handling on forward
All, On 1/11/16 9:21 PM, Mark Olsson wrote: > Adding = to a parameter does cause it to be available to the destination > servlet, but that doesn't seem like a particularly good solution. A > parameter without a value is technically a keyless value, not the other way > around. But I'll stick to the servlet terminology of calling them > parameter names and values since request.getParameterNames and > getParameterMap both return them as "Names" and not a value without a > name. Parameters without a value (keyless value) are widely used and > within spec without having to add the =. > > I wrote a couple of servlets and have been able to narrow down the problem > to take form POST data out of the equation, but not been able to find a > solution yet. I'm even more convinced that > getRequestDispatcher().forward() or the receiving servlet are borking the > parameters. > > This works: > Directly access /page1?a=1&b&c=3&d > The request arrives at the servlet with all 4 parameters, a and c have > values, b and d don't but are in the parameter names list. > > This doesn't work: > request.getRequestDispatcher("/page1?a=1&b&c=3&d").forward(request, > response); > The request arrives at the servlet with only the parameters a and c, not b > and d. All 4 parameters are in the query string, but b and d are not in > the parameter names list or map. > > Seems to me that if the exact same servlet can accept parameters without a > value on a direct request, but fails on only some parameters when it's from > a request dispatcher that something is wrong where the parameters are > gathered the second time, or somewhere before they are made available to > the destination. For the benefit of the archives: https://bz.apache.org/bugzilla/show_bug.cgi?id=58836 This issue was raised in BZ and will be fixed in Tomcat 8.0.31 as well as others. See the bug for details. Thanks, Mark, for the bug report and the test case. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Thomas, On 1/13/16 1:04 PM, Thomas Scheffler wrote: > Am 13.01.16 um 15:48 schrieb Christopher Schultz: >> Thomas, >> >> On 1/13/16 8:31 AM, Thomas Scheffler wrote: >>> Am 12.01.16 um 13:24 schrieb Mark Thomas: On 12/01/2016 11:06, Thomas Scheffler wrote: > Am 11.01.16 um 22:05 schrieb Mark Thomas: >>> >>> >> className="org.apache.catalina.authenticator.BasicAuthenticator" >>> changeSessionIdOnAuthentication="false" /> >>> >>> Found on >>> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection >>> >>> >>> the description how to switch the "feature" off. >>> >>> I will file two bugs soon describing the issues I had. Hopefully >>> they >>> will be fixed. >>> >>> 1.) if using HttpServetRequest.login(String, String) further >>> request in >>> the session are loosing the users Principal. >>> >>> 2.) After changing sessionId, old sessionIds should still be valid >>> for a >>> short period of time of to the same client. >> >> The second request will get closed as INVALID on security grounds. If >> the old ID is valid for any period of time it makes a session >> fixation >> attack possible. You might as well disable changing the session ID on >> authentication. >> >> For the first the description above isn't clear enough to be sure >> exactly what you are asking for. However, based on the second request >> and what I have read of this thread I suspect that request will get >> closed as INVALID or WONTFIX. > > Hi Mark, > > if you choose to use login() and this modifies the session ID. Further > calls to login() should either: > > 1.) are not required as every request belonging to the same session > are > already authenticated. After login() other request of the same session > will not return 'null' on getRemoteUser() or getUserPrincipal() > > 2.) are not required, as authenticate() use the information > provided by > the first login() call. > > 3.) do not modify the session ID as the same user was authenticated > before and the session is therefor safe to session fixation attacks Those 3 all boil down to essentially the same requirement. Requests are populated with cached authentication information from the session at the start of the request (if the authenticator is configured to do so - all but DIGEST are by default). >>> >>> Hi, >>> >>> "all but DIGEST are by default" was my case. >>> >>> As I walked through the code I found most of the features I requested >>> are already in place. There is already the tracking of the Principal in >>> the session. To use the values of login() later in authenticate() in >>> Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my >>> login-error-page. I think any value will do here ;-) >>> >>> >>> FORM >>> Restricted >>> >>> /foo >>> /bar >>> >>> >>> >>> This activates the FormAuthenticator which correctly does, what I was >>> hoping for. >>> >>> I think every authenticator can/should use the information stored by >>> login() if it is available. >> >> Which argument to login() carries the server-generated nonce used for >> login? Which argument includes the realm name? >> >> https://en.wikipedia.org/wiki/Digest_access_authentication > > Hi Chris, > > the login() method gets the username and the password. It has nothing to > do with configured auth-method in the web.xml. I'm familiar with this method and how it works. > Tomcat uses a generic > method[1] located in a super class do perform the login. The Principal > is stored in the session, if caching is enabled and a session is present > or created. > Depending on the configured auth-method the Principal is used later, if > found or not. My suggestion was to always use it, when it is stored in > the session. Tomcat can't verify that the incoming credentials match those credentials that were used in a previous login. How could Tomcat decide if new credentials were being used if Tomcat doesn't actually try to use them? Then, if Tomcat uses the credentials and they are valid, the session id must be changed for session-fixation prevention. If there is a difference between the BasicAuthenticator and the DigestAuthenticator, then that gap should probably be closed. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Client TLS 1.2 error for APR
On 13/01/2016 18:36, Harrie Robins wrote: > Hi! > > I'm running Tomcat 7.0.65 with APR connector over port 443. Tomcat version - tick Connector config - tick Tomcat-Native version ... ? Mark > I'm experiencing > trouble with users that connect with IE11 over SSL. Connecting and browsing > works fine, but sometimes a white screen with this error pops up. Once they > disable TLS 1.2 everything works fine: > > > > This page can't be displayed > > Turn on TLS 1.0, TLS1.1 and TLS 1.2 in Advanced settings and try connecting > to https://sub.example.com again. If this error persists, contact your site > administrator. > > > > Right now I'm using SHA-2 encryption (we moved from SHA-1) with A+ rating on > SSLLabs, without any error's. > > > > Server.xml configuration. Ciphers following latest intermediate from Mozilla > openssl config: > > > > > protocol="org.apache.coyote.http11.Http11AprProtocol" > > connectionTimeout="6000" > > maxThreads="500" > > maxKeepAliveRequests="-1" > > acceptCount="200" > > SSLEnabled="true" > > scheme="https" > > secure="true" > > clientAuth="false" > > enableLookups="false" > > SSLCertificateFile="C:\server\ssl\server.crt" > > SSLCertificateKeyFile="C: \server\ssl\private.key" > > SSLCACertificateFile="C: \server\ssl\intermediate.crt" > > SSLPassword="passw" > > SSLProtocol="all -SSLv2-SSLv3" > > SSLHonorCipherOrder="true" > SSLCipherSuite="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:EC > DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-S > HA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-EC > DSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES2 > 56-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256- > SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-A > ES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256- > GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DE > S-CBC3-SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC > _SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA: > !EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE:!EDH" > > /> > > > > Does anyone have a pointer about what could be wrong with this > configuration? > > > > Kind regards, > > > > Harrie > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Client TLS 1.2 error for APR
Hi! I'm running Tomcat 7.0.65 with APR connector over port 443. I'm experiencing trouble with users that connect with IE11 over SSL. Connecting and browsing works fine, but sometimes a white screen with this error pops up. Once they disable TLS 1.2 everything works fine: This page can't be displayed Turn on TLS 1.0, TLS1.1 and TLS 1.2 in Advanced settings and try connecting to https://sub.example.com again. If this error persists, contact your site administrator. Right now I'm using SHA-2 encryption (we moved from SHA-1) with A+ rating on SSLLabs, without any error's. Server.xml configuration. Ciphers following latest intermediate from Mozilla openssl config: Does anyone have a pointer about what could be wrong with this configuration? Kind regards, Harrie
RE: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service
My problem has been solved. In the tomcat7w.exe, I had to add the following to the Java Options: -Djava.library.path=C:\PROGRA~1\IBM\JazzTeamServer_601\server\tomcat\lib I also had to remove: -Xgc:preferredHeapBase=0x1 With the removal of -Xgc and the addition of the -Djava.library.path, the service successfully started. -Original Message- From: Terence M. Bandoian [mailto:tere...@tmbsw.com] Sent: Tuesday, January 12, 2016 6:46 PM To: Tomcat Users List Subject: RE: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service On 1/12/2016 10:04 AM, McDermott, Becky wrote: > I used the Java options provided by IBM. Since Tomcat will successfully > start using the startup batch files, I assume that these settings are fine. > I've tried playing with the settings and cannot get it to work either. I > seems like it's some sort of weird Windows thing. > > I have successfully configured these services before with prior version of > IBM's CLM. The difference in those previous versions was that Tomcat came > bundled with t heir product. For this latest IBM version, Tomcat was not > bundled and they provided instructions for downloading it from Apache and > instructions for where to install it. > > I have escalated the issue with IBM's support and since they are providing > the JVM, it is probably their issue but wanted to put it out to the larger > community to see if anyone has ever had this issue before. A user on the > user forums said that the memory error in the Tomcat log file is a red > herring and that it is giving that memory allocation error because the JVM > didn't actually start. So, the issue seems more connected to the error in > the Windows Event viewer ("cannot open file"). Hi, Becky- Have you tried the Tomcat Windows Service Installer available on the download page (http://tomcat.apache.org/download-70.cgi)? In my experience, it makes it much easier to get Tomcat up and running as a Windows service. In addition, a configuration app is included which further simplifies the process. With your current setup, I'd start by checking the Log On settings of the service and the permissions of the Tomcat files and folders. -Terence Bandoian > > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Tuesday, January 12, 2016 8:59 AM > To: Tomcat Users List > Subject: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows > Service > > Becky, > > On 1/12/16 10:42 AM, McDermott, Becky wrote: >> >I am integrating Tomcat with the IBM CLM 6.0.1 collaboration tools. Per >> >IBM's installation instructions, I downloaded and extracted Tomcat 7.0.59 >> >to my server. >> > >> >I am successfully able to start the Tomcat server from the command line >> >using the batch files provided by the IBM application (C:\Program >> >Files\IBM\JazzTeamServer_601\server\server.startup.bat). Tomcat starts as >> >well as all of the IBM CLM applications. >> > >> >The problem I'm having is when I try to configure tomcat to run as a >> >Windows service. I have followed the instructions provided by IBM: >> > >> > >> >1. Set the environment variable CATALINA_HOME to C:\Program >> >Files\IBM\JazzTeamServer_601\server\tomcat >> > >> >2. Deleted existing tomcat7 services using: sc delete tomcat7 >> > >> >3. Re-booted the machine > Note that, depending upon how you set the CATALINA_HOME environment variable, > rebooting will lose this value. I'm not sure the reboot was necessary. > >> >4. Installed the new tomcat service from the Tomcat bin directory: >> >service.bat install tomcat7 >> > >> >5. Configured the service using: tomcat7w.exe >> > >> >1. Clicked "Java" tab >> > >> >2. Cleared "Use default" checkbox >> > >> >3. Added the following path to the Java Virtual machine: C:\Program >> >Files\IBM\JazzTeamServer_601\server\jre\bin\j9vm\jvm.dll >> > >> >4. Added the following lines to the end of the java Options text >> >field: >> >-DJAZZ_HOME=file:///C:/PROGRA~1/IBM/JazzTeamServer_601/server/conf >> >-Djava.awt.headless=true >> >-Dorg.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcesPlugin= >> >tr ue -Dcom.ibm.team.repository.tempDir=C:\Program >> >Files\IBM\JazzTeamServer_601\server\tomcat\temp >> >-Djazz.connector.sslEnabledProtocols=TLSv1.2 >> >-Djazz.connector.algorithm=IbmX509 >> >-Dlog4j.configuration=file:///C:/PROGRA~1/IBM/JazzTeamServer_601/ser >> >ve >> >r/conf/startup_log4j.properties >> >-Xgcpolicy:gencon >> >-Xcompressedrefs >> >-Xgc:preferredHeapBase=0x1 >> >-XX:MaxDirectMemorySize=1G > That's a BIG buffer. Do you need 1G NIO buffers? A web-based video-editing > application? > >> >-Xmx4G >> >-Xms4G >> >-Xmn1g > What is -Xmn? It's probably not a problem, but I thought I'd point-out > something that looks weird. > >> >-DORACLE_JDBC_DRIVER_FILE=C:\Program >> >Files\IBM\JazzTeamServer_601\server\Oracle\ojdb6.jar >> > >> >5. Clear
Re: Tomcat 8.0.30 Session lost
Am 13.01.16 um 15:48 schrieb Christopher Schultz: Thomas, On 1/13/16 8:31 AM, Thomas Scheffler wrote: Am 12.01.16 um 13:24 schrieb Mark Thomas: On 12/01/2016 11:06, Thomas Scheffler wrote: Am 11.01.16 um 22:05 schrieb Mark Thomas: Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. For the first the description above isn't clear enough to be sure exactly what you are asking for. However, based on the second request and what I have read of this thread I suspect that request will get closed as INVALID or WONTFIX. Hi Mark, if you choose to use login() and this modifies the session ID. Further calls to login() should either: 1.) are not required as every request belonging to the same session are already authenticated. After login() other request of the same session will not return 'null' on getRemoteUser() or getUserPrincipal() 2.) are not required, as authenticate() use the information provided by the first login() call. 3.) do not modify the session ID as the same user was authenticated before and the session is therefor safe to session fixation attacks Those 3 all boil down to essentially the same requirement. Requests are populated with cached authentication information from the session at the start of the request (if the authenticator is configured to do so - all but DIGEST are by default). Hi, "all but DIGEST are by default" was my case. As I walked through the code I found most of the features I requested are already in place. There is already the tracking of the Principal in the session. To use the values of login() later in authenticate() in Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my login-error-page. I think any value will do here ;-) FORM Restricted /foo /bar This activates the FormAuthenticator which correctly does, what I was hoping for. I think every authenticator can/should use the information stored by login() if it is available. Which argument to login() carries the server-generated nonce used for login? Which argument includes the realm name? https://en.wikipedia.org/wiki/Digest_access_authentication Hi Chris, the login() method gets the username and the password. It has nothing to do with configured auth-method in the web.xml. Tomcat uses a generic method[1] located in a super class do perform the login. The Principal is stored in the session, if caching is enabled and a session is present or created. Depending on the configured auth-method the Principal is used later, if found or not. My suggestion was to always use it, when it is stored in the session. Hope this clarifies my summary. Thomas [1] org.apache.catalina.authenticator.AuthenticatorBase.doLogin(Request, String, String) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Thomas, On 1/13/16 8:31 AM, Thomas Scheffler wrote: > Am 12.01.16 um 13:24 schrieb Mark Thomas: >> On 12/01/2016 11:06, Thomas Scheffler wrote: >>> Am 11.01.16 um 22:05 schrieb Mark Thomas: > > className="org.apache.catalina.authenticator.BasicAuthenticator" > changeSessionIdOnAuthentication="false" /> > > Found on > http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection > > the description how to switch the "feature" off. > > I will file two bugs soon describing the issues I had. Hopefully they > will be fixed. > > 1.) if using HttpServetRequest.login(String, String) further > request in > the session are loosing the users Principal. > > 2.) After changing sessionId, old sessionIds should still be valid > for a > short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. For the first the description above isn't clear enough to be sure exactly what you are asking for. However, based on the second request and what I have read of this thread I suspect that request will get closed as INVALID or WONTFIX. >>> >>> Hi Mark, >>> >>> if you choose to use login() and this modifies the session ID. Further >>> calls to login() should either: >>> >>> 1.) are not required as every request belonging to the same session are >>> already authenticated. After login() other request of the same session >>> will not return 'null' on getRemoteUser() or getUserPrincipal() >>> >>> 2.) are not required, as authenticate() use the information provided by >>> the first login() call. >>> >>> 3.) do not modify the session ID as the same user was authenticated >>> before and the session is therefor safe to session fixation attacks >> >> Those 3 all boil down to essentially the same requirement. >> >> Requests are populated with cached authentication information from the >> session at the start of the request (if the authenticator is configured >> to do so - all but DIGEST are by default). > > Hi, > > "all but DIGEST are by default" was my case. > > As I walked through the code I found most of the features I requested > are already in place. There is already the tracking of the Principal in > the session. To use the values of login() later in authenticate() in > Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my > login-error-page. I think any value will do here ;-) > > > FORM > Restricted > > /foo > /bar > > > > This activates the FormAuthenticator which correctly does, what I was > hoping for. > > I think every authenticator can/should use the information stored by > login() if it is available. Which argument to login() carries the server-generated nonce used for login? Which argument includes the realm name? https://en.wikipedia.org/wiki/Digest_access_authentication -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: property replacement in WEB-INF/web.xml
André, On 1/13/16 9:36 AM, André Warnier (tomcat) wrote: > Hi gurus. > > Under tomcat 8 and Linux, I am deploying an externally-provided web > application, which in its web.xml configuration file, has a parameter > like this : > > > logroot > /var/log/tomcat8 > > > This works, but I would like to make this more "generic", and would like > to replace the above param-value by something like this : > > > logroot > ${CATALINA_BASE}/logs > > > with CATALINA_BASE being the well-known environment value set prior to > starting (the JVM which runs) Tomcat (and "${CATALINA_BASE}/logs" being > actually a link which points to "/var/log/tomcat8" in this case). > > Can I do this ? and if yes, what is the exact way to do this right ? > > (In a log4j configuration file, I can use "${env:CATALINA_BASE}" for > this, but this is not available under Tomcat, or is it ?) I think you want to use the system property version of that value, which is: logroot I can't find it in the Tomcat documentation that this will work in a web application's web.xml, but that's definitely how it works for server.xml -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
property replacement in WEB-INF/web.xml
Hi gurus. Under tomcat 8 and Linux, I am deploying an externally-provided web application, which in its web.xml configuration file, has a parameter like this : logroot /var/log/tomcat8 This works, but I would like to make this more "generic", and would like to replace the above param-value by something like this : logroot ${CATALINA_BASE}/logs with CATALINA_BASE being the well-known environment value set prior to starting (the JVM which runs) Tomcat (and "${CATALINA_BASE}/logs" being actually a link which points to "/var/log/tomcat8" in this case). Can I do this ? and if yes, what is the exact way to do this right ? (In a log4j configuration file, I can use "${env:CATALINA_BASE}" for this, but this is not available under Tomcat, or is it ?) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
Rahul, On 1/12/16 10:56 PM, Rahul Singh wrote: > Hi, > >> Define "Not successful"? Exceptions thrown? File truncated? Upload >> never starts? Never finishes? > > Not successful : > > Request Never finishes, we have trace the HttpServlet request object > and request.getContentLength return 0 in case when file size is >=2GB, > > No exception thrown, as well as when file size is less than 2GB, then > request.getContentLength return the correct value of file size in > byte. ServletRequest.getContentLength is declared to return an int value (32-bit): * Integer.MAX_VALUE = 2^31 - 1 = 2147483647 * 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648 * 2147483648 > 2147483647 Therefore, request.getContentLength cannot be used to fetch content-lengths over 2GiB - 1byte. You have to use ServletRequest.getContentLengthLong (new in servlet 3.1) or call HttpServletRequest.getHeader("Content-Length") as a String and parse it yourself. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 12.01.16 um 13:24 schrieb Mark Thomas: On 12/01/2016 11:06, Thomas Scheffler wrote: Am 11.01.16 um 22:05 schrieb Mark Thomas: Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. For the first the description above isn't clear enough to be sure exactly what you are asking for. However, based on the second request and what I have read of this thread I suspect that request will get closed as INVALID or WONTFIX. Hi Mark, if you choose to use login() and this modifies the session ID. Further calls to login() should either: 1.) are not required as every request belonging to the same session are already authenticated. After login() other request of the same session will not return 'null' on getRemoteUser() or getUserPrincipal() 2.) are not required, as authenticate() use the information provided by the first login() call. 3.) do not modify the session ID as the same user was authenticated before and the session is therefor safe to session fixation attacks Those 3 all boil down to essentially the same requirement. Requests are populated with cached authentication information from the session at the start of the request (if the authenticator is configured to do so - all but DIGEST are by default). Hi, "all but DIGEST are by default" was my case. As I walked through the code I found most of the features I requested are already in place. There is already the tracking of the Principal in the session. To use the values of login() later in authenticate() in Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my login-error-page. I think any value will do here ;-) FORM Restricted /foo /bar This activates the FormAuthenticator which correctly does, what I was hoping for. I think every authenticator can/should use the information stored by login() if it is available. kind regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 Application dispatcherServlet Stats
Hello - at the moment stats can be found for Tomcat 8 web services using the manager UI /manager/status/all Is the "Processing time" metric found under dispatcherServlet [ / ] subsection, the total time take to serve all requests, including the response time for each request? Regards, Theo Avios Group (AGL) Ltd is a limited company registered in England (registered number 2260073 and VAT number 512566754) whose registered address is Astral Towers, Betts Way, London Road, Crawley, West Sussex RH10 9XY . Avios Group (AGL) Limited is part of the IAG group of companies This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
Hi André Warnier, its 64 bit (OS and JVM) From: André Warnier (tomcat) Sent: Wednesday, January 13, 2016 2:17 PM To: users@tomcat.apache.org Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79] maybe a stupid question nowadays, but : is the platform on which you are running this 32-bit, or 64-bit ? (OS and JVM) On 13.01.2016 04:56, Rahul Singh wrote: > Hi, > >> Define "Not successful"? Exceptions thrown? File truncated? Upload >> never starts? Never finishes? > > Not successful : > > Request Never finishes, we have trace the HttpServlet request object and > request.getContentLength return 0 in case when file size is >=2GB, > > No exception thrown, as well as when file size is less than 2GB, then > request.getContentLength return the correct value of file size in byte. > > > Regards, > Rahul Kumar Singh > > From: David kerber > Sent: Tuesday, January 12, 2016 6:07 PM > To: Tomcat Users List > Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 > Struts: 2.3.24 JAVA: openJDK 1.7.79] > > On 1/12/2016 12:01 AM, Rahul Singh wrote: >> >> Hello Apache Tomcat team, >> >> Sending again with some corrections, >> >> File upload in my application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK >> 1.7.79) is not successful for greater than 2 gb. After previous discussion >> here on previous thread, I migrated my application to struts 2.3.24 as the >> only possible solution in form of jakarta-stream parser for large size >> uploads (greater than 2gb). >> But after successfully migrating to struts 2.3.24 from 2.1.8, file upload >> greater than 2 gb still not supported. I want to use jakarta-streams for >> this purpose.Following is the code >> snippet: >> >> >> In struts.xml: >> >> >> >> >> >> In JSP: >> === >> >> > namespace="xyz" validateFields="false" method="post" >> enctype="multipart/form-data"> >> >> >> Alongwith with configuring server.xml with maxPostSize element and >> mutipart-config in web.xml But still the file upload request for greater >> than 2 gb not successful. > > Define "Not successful"? Exceptions thrown? File truncated? Upload > never starts? Never finishes? > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
maybe a stupid question nowadays, but : is the platform on which you are running this 32-bit, or 64-bit ? (OS and JVM) On 13.01.2016 04:56, Rahul Singh wrote: Hi, Define "Not successful"? Exceptions thrown? File truncated? Upload never starts? Never finishes? Not successful : Request Never finishes, we have trace the HttpServlet request object and request.getContentLength return 0 in case when file size is >=2GB, No exception thrown, as well as when file size is less than 2GB, then request.getContentLength return the correct value of file size in byte. Regards, Rahul Kumar Singh From: David kerber Sent: Tuesday, January 12, 2016 6:07 PM To: Tomcat Users List Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79] On 1/12/2016 12:01 AM, Rahul Singh wrote: Hello Apache Tomcat team, Sending again with some corrections, File upload in my application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79) is not successful for greater than 2 gb. After previous discussion here on previous thread, I migrated my application to struts 2.3.24 as the only possible solution in form of jakarta-stream parser for large size uploads (greater than 2gb). But after successfully migrating to struts 2.3.24 from 2.1.8, file upload greater than 2 gb still not supported. I want to use jakarta-streams for this purpose.Following is the code snippet: In struts.xml: In JSP: === Alongwith with configuring server.xml with maxPostSize element and mutipart-config in web.xml But still the file upload request for greater than 2 gb not successful. Define "Not successful"? Exceptions thrown? File truncated? Upload never starts? Never finishes? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org