Re: OOME issue in Tomcat 6.0.18(with SSL)
Hi Chris,
A little more digging in and I found out that only with SSL,tomcat is creating
a large number of sessions. I can see in the logs for HTTP:
INFO: SessionListener: sessionDestroyed('2E8DE01EE3F0D166FEFC8A45353CD9ED')
Now,in case of HTTPS I see a large number of such logs. So I believe for HTTPS
requests it is creating a session for every request as compared to HTTP?
This is my SSL setting in client:
public HttpTLSProtocolSocketFactory()
{
try
{
this.sslcontext = SSLContext.getInstance("TLS");
TrustManager[] arrayOfTrustManager = { new DummyX509TrustManager() };
this.sslcontext.init(null, arrayOfTrustManager, null);
}
catch (Exception localException)
{
this.logger.log(Level.SEVERE, "Failed to created SSLContext: " +
localException.getMessage());
}
}
public Socket createSocket(String paramString, int paramInt1, InetAddress
paramInetAddress, int paramInt2, HttpConnectionParams paramHttpConnectionParams)
throws IOException, UnknownHostException, ConnectTimeoutException
{
if (paramHttpConnectionParams == null)
throw new IllegalArgumentException("Parameters may not be null");
int i = paramHttpConnectionParams.getConnectionTimeout();
SSLSocketFactory localSSLSocketFactory = this.sslcontext.getSocketFactory();
if (i == 0)
return localSSLSocketFactory.createSocket(paramString, paramInt1,
paramInetAddress, paramInt2);
Socket localSocket = localSSLSocketFactory.createSocket();
InetSocketAddress localInetSocketAddress1 = new
InetSocketAddress(paramInetAddress, paramInt2);
InetSocketAddress localInetSocketAddress2 = new
InetSocketAddress(paramString, paramInt1);
localSocket.bind(localInetSocketAddress1);
localSocket.connect(localInetSocketAddress2, i);
return localSocket;
}
Can different sockets create different sessions?
So for HTTP I am not creating any new sessions,same should be the case for
HTTPS. Right?
The only thing which differs in my is the SSLSocketFactory Implementation,which
creates sockets.
Chirag.
From: Christopher Schultz
To: Tomcat Users List
Sent: Wednesday, 12 June 2013 8:14 PM
Subject: Re: OOME issue in Tomcat 6.0.18(with SSL)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 6/12/13 1:01 AM, Chirag Dewan wrote:
> I am facing an Out of Memory Issue with my application. I am using
> Embedded Tomcat 6.0.18. I have a simple servlet deployed which
> does nothing but set the HTTPResponse and return it.
Are you sure you don't trigger session creation?
> Now I have 2 testing clients
>
> Client 1:
>
> HTTPClient 3.1 with MultiThreadedHttpConnectionManager with SSL
> maxConnections = 200 maxConnectionsPerHost=200
>
> Client 2:
>
> HTTPClient 4.1 in which I configured multiple threads
>
> for (int i = 0; i < noofConnections; i++) { Thread t = new
> Thread(my); t.start(); }
What is noofConnections set to?
> With every thread executing HTTPGet on the servlet. This too with
> SSL.
>
>
> Now with client 1,my JVM crashes after just a few minutes. Running
> with 8gb heap space.
>
>
> I took a heap dump for 2gb heap space using Jmap and analyzed it
> with MAT. It seems that there were many instances of
> org.apache.catalina.session.StandardManager consuming almost 95% of
> heap space.
There should only be one StandardManager present per web application
deployed. You only have a single web application? Are you sure that
you have many StandardManager instances, or do you have a single
StandardManager with a huge number of sessions?
> CPU utilization is only 13 -14% and I can see only 65 threads
> active with netstat.
>
>
> With Client 2,everything looks fine. Though JVM crashes at 2gb,but
> at 8gb it works fine. Though CPU utilization is almost 90% and 100
> simultaneous threads created for 100 simultaneous threads.
>
> Both my server and clients are on Linux 64 bit machines.
>
> I believe that this is something related to the client 1 i.e.
> either the HTTPClient 3.1 or the MultiThreadedConnectionManager,but
> posting here if someone can assist me in what might be the root
> cause.
Try a single thread and a single connection. Take a packet-capture and
see what the response headers look like. I wouldn't be surprised if
you are generating a new session with each and every request.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRuIlpAAoJEBzwKT+lPKRYjo4P/2S+89ycBzPTnxonur/aTUxm
0ZIHWHsDbKlg7YRlMlvpcPGuyXniW9mDOw5wWajt4WSCmcWNDEfI3bIIAI139lkw
EeEFIVplkK/ZY2uLViJ0B4V9A/kBB7qkGDNPPubeNnhpi6gVGl+j3jB1S9aHOT9t
dmLGavG1j1pRtAUTItr1kVKAegyaYCSlwbDe8YQefRF8+N/DyAi3wutSdoOpGYMA
WytWWW4QvnFCZF3BcS13AhMgcPM/j81tQUtfnjLDIjV4KmAZwoF8i/4ZE21+Twl6
XfrFQve4DK+AhjGfqkobGKm1AlUycqI+8BGKbjEhtcOAmavfQDVtuV90Ahmb2gWd
9tNEf/EhQZuQcX5Gqg3WI7Ut7gz/9/f5i4P+1MN6AwwDTt7EJ0yl975+4eaz
RE: Illegal access: this web application instance has been stopped already and NoClassDefFoundError
Hi Chris,
>
> On 6/11/13 1:05 AM, ruxing bao wrote:
> > Sorry,I can't get any more of the stack trace.
> >
> > We wrapped zookeepr client as a spring bean and invoked method
> > "close" of zookeeper in "destory-method" of bean,in that method
> > "close",zookeeper Send Thread was closed. When tomcat was shut
> > down, Spring closed it's container and bean was destroyed, then
> > "destroy-method" of bean was invoked. I'am confusing why is Send
> > Thread of Zookeeper seemed to exit slower than the
> > WebappClassLoader shedding its loaded classes.
>
>
> Threads don't always shut down immediately... let's see how you are
> telling the thread to shut down:
>
> > ps: details of zookeeper closing
>
> (Thanks!)
>
> > org.apache.zookeeper.Zookeeper public synchronized void close()
> > throws InterruptedException { if (!cnxn.getState().isAlive()) { if
> > (LOG.isDebugEnabled()) { LOG.debug("Close called on already closed
> > client"); } return; } if (LOG.isDebugEnabled()) {
> > LOG.debug("Closing session: 0x" +
> > Long.toHexString(getSessionId())); } try { cnxn.close(); } catch
> > (IOException e) { if (LOG.isDebugEnabled()) { LOG.debug("Ignoring
> > unexpected exception during close", e); } } LOG.info("Session: 0x"
> > + Long.toHexString(getSessionId()) + " closed"); }
>
> So, during webapp shutdown you should be getting the message "Closing
> session 0x[...]", right? No errors?
Yes, no errors.
> Is "cnxn" of type org.apache.zookeeped.ClientCnxn? That seems to be
> the case, but it's worth checking.
>
> > --
> >
> >
> org.apache.zookeeper.ClientCnxn
> > public void close() throws IOException { if (LOG.isDebugEnabled())
> > { LOG.debug("Closing client for session: 0x" +
> > Long.toHexString(getSessionId())); } try { RequestHeader h = new
> > RequestHeader(); h.setType(ZooDefs.OpCode.closeSession);
> > submitRequest(h, null, null, null); } catch (InterruptedException
> > e) { // ignore, close the send/event threads } finally {
> > disconnect(); } }
> >
> > public void disconnect() { if (LOG.isDebugEnabled()) {
> > LOG.debug("Disconnecting client for session: 0x" +
> > Long.toHexString(getSessionId())); } sendThread.close();
> > eventThread.queueEventOfDeath(); }
>
> Okay, so calling "close" asks the thread to stop (somewhat indirectly).
>
> > org.apache.zookeeper.ClientCnxn.SendThread void close() { state =
> > States.CLOSED; clientCnxnSocket.wakeupCnxn(); }
> >
> >
> > @Override public void run() {
> > clientCnxnSocket.introduce(this,sessionId);
> > clientCnxnSocket.updateNow();
> > clientCnxnSocket.updateLastSendAndHeard(); int to; long
> > lastPingRwServer = System.currentTimeMillis(); while
> > (state.isAlive()) { try { if (!clientCnxnSocket.isConnected()) {
> > if(!isFirstConnect){ try { Thread.sleep(r.nextInt(1000)); } catch
> > (InterruptedException e) { LOG.warn("Unexpected exception", e); }
> > } // don't re-establish connection if we are closing if (closing ||
> > !state.isAlive()) { break; } startConnect();
> > clientCnxnSocket.updateLastSendAndHeard(); } if
> > (state.isConnected()) { // determine whether we need to send an
> > AuthFailed event. if (zooKeeperSaslClient != null) { boolean
> > sendAuthEvent = false; if (zooKeeperSaslClient.getSaslState() ==
> > ZooKeeperSaslClient.SaslState.INITIAL) { try {
> > zooKeeperSaslClient.initialize(ClientCnxn.this); } catch
> > (SaslException e) { LOG.error("SASL authentication with Zookeeper
> > Quorum member failed: " + e); state = States.AUTH_FAILED;
> > sendAuthEvent = true; } } KeeperState authState =
> > zooKeeperSaslClient.getKeeperState(); if (authState != null) { if
> > (authState == KeeperState.AuthFailed) { // An authentication error
> > occurred during authentication with the Zookeeper Server. state =
> > States.AUTH_FAILED; sendAuthEvent = true; } else { if (authState ==
> > KeeperState.SaslAuthenticated) { sendAuthEvent = true; } } } if
> > (sendAuthEvent == true) { eventThread.queueEvent(new WatchedEvent(
> > Watcher.Event.EventType.None, authState,null)); } } to =
> > readTimeout - clientCnxnSocket.getIdleRecv(); } else { to =
> > connectTimeout - clientCnxnSocket.getIdleRecv(); }
> >
> > if (to <= 0) { throw new SessionTimeoutException( "Client session
> > timed out, have not heard from server in " +
> > clientCnxnSocket.getIdleRecv() + "ms" + " for sessionid 0x" +
> > Long.toHexString(sessionId)); } if (state.isConnected()) { int
> > timeToNextPing = readTimeout / 2 - clientCnxnSocket.getIdleSend();
> > if (timeToNextPing <= 0) { sendPing();
> > clientCnxnSocket.updateLastSend(); } else { if (timeToNextPing <
> > to) { to = timeToNextPing; } } } // If we are in read-only mode,
> > seek for read/write server if (state == States.CONNECTEDREADONLY)
> > { long now = System.currentTimeMillis(); int idlePingRwServer =
> > (int) (now - lastPingRwServer); if (idlePingRwServer >=
> > pingRwTimeout) { la
RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
> > I'm fairly confident that the OpenSSL library I'm using is valid and > > uncorrupted (I've used a couple different copies: an existing set of > > binaries being used successfully in another product internally, and a > > newly built version which I have successfully used the openssl utility > > against, without error). > > Can you write a simple C program to link against OpenSSL and try to start it > in > FIPS mode? Does that work without error? Feel free to just steal code from > tcnative to put-together a Frankenstein's monster of code just to see if it > works. I've done so, and verified that my OpenSSL build seems to be working correctly, both in FIPS mode and not. My test program creates SHA-1 and MD5 hashes of a simple string value. With FIPS mode off, both hashes are returned. With FIPS mode on, the SHA-1 hash is returned, and the MD5 hash generates the expected "disabled for fips" error. There was no error at the point of FIPS_mode_set(1), which seems to indicate that the self tests passed. This matches what I saw when I used the openssl.exe utility that was compiled with OpenSSL (version OpenSSL 1.0.1c-fips 10 May 2012). Using this same OpenSSL build in tcnative, however, results in the fingerprint error when Tomcat starts up with FIPS mode enabled. > > My assumption is that I'm not building/linking OpenSSL correctly into > > tcnative. > > ...and you are building tcnative by hand because the OpenSSL Tomcat > provides is not build with FIPS compatibility, right? You will have to make > sure > you have a FIPS-compatible OpenSSL (please post the result of "openssl.exe > version") and you will definitely have to re-build tcnative against it because > otherwise all the FIPS stuff will generate errors before even trying to call > FIPS_mode_set on OpenSSL. Correct. I get the expected "FIPS not available" error when I turn on FIPS mode using the stock tcnative-1.dll library that comes with Tomcat. The FIPS-compatible OpenSSL build I have reports as "OpenSSL 1.0.1c-fips 10 May 2012". > I notice that Tomcat distributes openssl.exe and not openssl.dll (or similar). > Are you building openssl.exe or openssl.dll when you build OpenSSL? Building OpenSSL on Windows results in three distributable files: libeay32.dll, ssleay32.dll, and openssl.exe. I copy the first two into Tomcat\bin, along with tcnative-1.dll, in order to make OpenSSL available to tcnative. It also results in libeay32.lib and ssleay32.lib, which are used in the tcnative compile process. --Steve Nickels Ipswitch, Inc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Problem was solved by removing an old catalina.jar for WEB-INF/lib. The fact that you had a Tomcat-supplied jar in WEB-INF/lib is even scarier than using a three-year-old unreleased level. Tomcat-supplied jars must *NEVER* be placed anywhere other than in Tomcat's lib directory. Sounds like you need to do a comprehensive audit of your webapp development and deployment process. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
Thanks much. Problem was solved by removing an old catalina.jar for WEB-INF/lib. JMuse -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, June 11, 2013 7:38 PM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 > From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: Class cast exception when starting tomcat 7.0.1 > I'm getting a class cast exception when starting up tomcat 7.0.1 You can't be serious. That version was never released, and would be almost three years old if it had been. Use the current version: 7.0.41. Do a fresh download and clean install, verify that Tomcat is working, then add your webapps one by one, insuring that each one operates properly before trying the next. Do not directly copy any configuration from previous versions of Tomcat to the new one; modify the conf/*.xml files with whatever you need for your installation. Also make sure you do not have the same classes in tomcat's lib directory and the webapp's WEB-INF/lib or WEB-INF/classes directories. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: is tomcat 6.0.35 vulnerable to CVE-2007-6750?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Brandon, On 6/12/13 12:33 PM, Brandon McCombs wrote: > So it seems that although there is a chance of Tomcat being > vulnerable [to Slowloris] it isn't a sufficiently large risk to > warrant being addressed and is in fact categorized as a low risk. That depends upon your perspective. Unfortunately, Slowloris is a fairly effective weapon under certain conditions. The reason it's difficult to mitigate is that it is not really possible to differentiate a Slowloris attack from a client using a really crappy connection (mobile, etc.) from just a single sample (i.e. one request). mod_security and a few other httpd modules can do things like detect multiple connections from a single host acting funny and kill them all. Tomcat has no such built-in mitigations. If you use the NIO connector (or APR?), you can at least limit the DOS to exhausting your file handles, since the headers are read asynchronously and therefore don't tie-up threads during that lng, slow request. Setting a reasonable connectionTimeout (default: 60s, default-configuration: 20s) can abort a connection somewhat early, but a Slowloris client that sends a request line immediately and then sends one byte per second in a chunked request can tie you up virtually forever. You can also tweak connectionUploadTimeout. You could write a Valve that queued pending requests including a start-time and periodically sweep that queue for long-running requests but you would a) find it difficult to identify true attacks versus other factors and b) it's very messy to kill a request's socket while the client is still sending. (Search the archives for posts about aborting client-uploads for further, related reading). > So that's good enough for me. It's nice to hear someone come onto the list asking about a CVE and ultimately say "wow, that sucks, but I guess it's okay to leave things alone." Mostly, people come and demand patches so they can pass a security audit ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuMHDAAoJEBzwKT+lPKRYOQkP/iA778vfIw6x7/wbWmDkKCrV 0QvOhjnZbm+Fxqq2XIpzGnrYyoJwK9lLSr8FfVn7g7LlN0DcLaG/aNIIzxusWh/+ 4AN8W6qXdDWnGxQMEhX/zZDNWqlj0CV/YQ/JM2DiU9whPuWzIENmAUiHD5t5l9Sj fCe9AMgylgZUyUs2LpditJmXsdbWC6bP4nQf72AYysY1LXLRGsxrcLjHGe+lOXhq 9M+G/rhG1u1AVMOvZDc9kEJESC/XgyQvgejf6T/5gZge2RGxyT22D1vTUfo1yVBZ 7bQdtoSvQJbMzk2dnV+ISj+pkcU6yNUq7W8XZc4jqMXlWNaB6m5uCCbZSgFqpQz0 ee9xDl3G/7ELr8ujSSgJlpJp6jzh+5wWCqvYcQegyMjICzbY83lZxdTQTZqQhIJ5 7Scot/QrleC0ziLl9XWFX8LLFGoIQ/Gzwt2KYbmUrL4UadcyN52XRYfs3n9Qm4ll DAb8/P5dXfI+SII6sQ51eGWg7fT3M+WAuh8MCrB8EuZaoWAXYn+SJuoBFGFfULrd xPPaCHPdCE3FRGtt2CRxSUXlWJhWjblvy5Sjp64FNr6t8JLEa6Hv48w+EDZhyYj0 Aumn38/9CZqZyajcUP8pMEU4cuNKXyH8FV2Icqde0AF/69h9KLPmarz56PhhsgRk DWu5psesFCU+v3AZX/dP =Q9Dt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: is tomcat 6.0.35 vulnerable to CVE-2007-6750?
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, June 12, 2013 11:56 AM To: Tomcat Users List Subject: Re: is tomcat 6.0.35 vulnerable to CVE-2007-6750? > >Brandon, > >On 6/12/13 11:33 AM, Brandon McCombs wrote: >> I don't know if this is the correct list but it seem to be the best >> one. >> >> I'm trying to find evidence of whether tomcat 6.0.35 is vulnerable >> (and if so, was it fixed and in which version?) to the issue >> identified in CVE-2007-6750? > >Note that, officially, CVE-2007-6750 is against Apache httpd, and no other >product. Technically, CVE-2007-6750 cannot be applied to Tomcat. > >On the other hand, the technique used for a DOS (Slowloris) can definitely be >used to DOS Tomcat under certain configurations. >Technically, this is tracked via a separate CVE issue: >http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5568 (which you should >have found from RedHat's Bugzilla entry). > > Hi Chris Yeah I found it. I don't think I noticed I had found it when I clicked on that entry in my Google search results. I just saw CVE-2007-6750 listed in the short excerpt and clicked on it. The bugzilla url I listed below is actually from that CVE page for 5568. > >To (partially) mitigate Slowloris, use the NIO connector with an appropriate >connectionTimeout configured. > >> "The Apache HTTP Server 1.x and 2.x allows remote attackers to cause a >> denial of service (daemon outage) via partial HTTP requests, as >> demonstrated by Slowloris, related to the lack of the mod_reqtimeout >> module in versions before 2.2.15." >> >> I found a single statement on >> https://bugzilla.redhat.com/show_bug.cgi?id=880011 that says Tomcat is >> affected but I haven't found any published fix from RH or any >> confirmation on tomcat.apache.org website. > >http://tomcat.apache.org/security-7.html#Not_a_vulnerability_in_Tomcat > >You are looking for CVE-2012-5568. I remember reading the description for 5568 on the security-7.html page but since I didn't know (or notice) that was the one that was specific to tomcat for the general 6750 issue I didn't put 2 and 2 together. So it seems that although there is a chance of Tomcat being vulnerable it isn't a sufficiently large risk to warrant being addressed and is in fact categorized as a low risk. So that's good enough for me. Thank you sir. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: is tomcat 6.0.35 vulnerable to CVE-2007-6750?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Brandon, On 6/12/13 11:33 AM, Brandon McCombs wrote: > I don't know if this is the correct list but it seem to be the > best one. > > I'm trying to find evidence of whether tomcat 6.0.35 is vulnerable > (and if so, was it fixed and in which version?) to the issue > identified in CVE-2007-6750? Note that, officially, CVE-2007-6750 is against Apache httpd, and no other product. Technically, CVE-2007-6750 cannot be applied to Tomcat. On the other hand, the technique used for a DOS (Slowloris) can definitely be used to DOS Tomcat under certain configurations. Technically, this is tracked via a separate CVE issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5568 (which you should have found from RedHat's Bugzilla entry). To (partially) mitigate Slowloris, use the NIO connector with an appropriate connectionTimeout configured. > "The Apache HTTP Server 1.x and 2.x allows remote attackers to > cause a denial of service (daemon outage) via partial HTTP > requests, as demonstrated by Slowloris, related to the lack of the > mod_reqtimeout module in versions before 2.2.15." > > I found a single statement on > https://bugzilla.redhat.com/show_bug.cgi?id=880011 that says > Tomcat is affected but I haven't found any published fix from RH or > any confirmation on tomcat.apache.org website. http://tomcat.apache.org/security-7.html#Not_a_vulnerability_in_Tomcat You are looking for CVE-2012-5568. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuJn3AAoJEBzwKT+lPKRYCUQP/3HVXBjBtHuUG/SgowZ4xy9l sKz336AeLtDkTcwcJKnblXvCf62KjBKELO06/Yl6QOAafhbsDfloSNJY/MxNNwgR y1e7KUHhSOKzf49+cxiW2KTqGMVJLLkMX24OzaqeOVBqxlRg89BjBYH4HGQUH9w7 DuoeoEWcxKviFZrMCDlUoL/hgB8r23aHA9eqKUkO2Lfz+V7gCl4ANQ8xEhIjaQlm amqG8F8j8TOxeoKLuG1w5nPpQHmpwQvrSYNd/czxQHPqne4W6VFgA4GqDDoVGZzT EbJpiqsSOiw3/GqCJOlDFZVipDnx4jrzhlo1S5r7XbAP9robTxwDfg6HvXekKgNH trpjNbp8joty7rJ4dQFeQqEKuK+mRKorWx5uLmDJpD8baOIxhlr4TvsE8N+BNLfD dCmrLYn7QYbqsPga9ujpDbM73ZbzWkdVi+W6o8+XHyxiwaFgUawe0BEJujCtjGBO ZmapaH7ondBGajZLKltnH5c+JGydTl7G/6V4ZndMzPclgoWGLHopb9jOThJLeT7b PuIhpAlEfbJLeZQPlsJILTsbd4eqi8YXlbEpykgUTXR/LIfCqMIHx0PmCPELYyJC y/7xLI6GXG5kmgvRnZMoLTuYF55trJG3IuxKvt/9KEm9UlO6x64E+iz+D3R6HyFU zfgqa1ec8Mw+qZmcOdhb =uuaV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
is tomcat 6.0.35 vulnerable to CVE-2007-6750?
I don't know if this is the correct list but it seem to be the best one. I'm trying to find evidence of whether tomcat 6.0.35 is vulnerable (and if so, was it fixed and in which version?) to the issue identified in CVE-2007-6750? "The Apache HTTP Server 1.x and 2.x allows remote attackers to cause a denial of service (daemon outage) via partial HTTP requests, as demonstrated by Slowloris, related to the lack of the mod_reqtimeout module in versions before 2.2.15." I found a single statement on https://bugzilla.redhat.com/show_bug.cgi?id=880011 that says Tomcat is affected but I haven't found any published fix from RH or any confirmation on tomcat.apache.org website. Any info would be great. thanks Brandon McCombs -- Brandon McCombs LogLogic Technical Support and Professional Services Engineer TIBCO Software, Inc. Office: 1-304-816-4488
Re: mod_jk worker activation not working anymore in 1.2.37?
On 06/11/2013 06:42 AM, Rainer Jung wrote: On 11.06.2013 00:58, Martin Knoblauch wrote: Any plans when 1.2.38 will be released? Not really, but it is overdue. So IMO we should release it during the next few weeks. Yeah. There are few more reported bugs for updating status which I'd like to check before new release. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OOME issue in Tomcat 6.0.18(with SSL)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 6/12/13 1:01 AM, Chirag Dewan wrote:
> I am facing an Out of Memory Issue with my application. I am using
> Embedded Tomcat 6.0.18. I have a simple servlet deployed which
> does nothing but set the HTTPResponse and return it.
Are you sure you don't trigger session creation?
> Now I have 2 testing clients
>
> Client 1:
>
> HTTPClient 3.1 with MultiThreadedHttpConnectionManager with SSL
> maxConnections = 200 maxConnectionsPerHost=200
>
> Client 2:
>
> HTTPClient 4.1 in which I configured multiple threads
>
> for (int i = 0; i < noofConnections; i++) { Thread t = new
> Thread(my); t.start(); }
What is noofConnections set to?
> With every thread executing HTTPGet on the servlet. This too with
> SSL.
>
>
> Now with client 1,my JVM crashes after just a few minutes. Running
> with 8gb heap space.
>
>
> I took a heap dump for 2gb heap space using Jmap and analyzed it
> with MAT. It seems that there were many instances of
> org.apache.catalina.session.StandardManager consuming almost 95% of
> heap space.
There should only be one StandardManager present per web application
deployed. You only have a single web application? Are you sure that
you have many StandardManager instances, or do you have a single
StandardManager with a huge number of sessions?
> CPU utilization is only 13 -14% and I can see only 65 threads
> active with netstat.
>
>
> With Client 2,everything looks fine. Though JVM crashes at 2gb,but
> at 8gb it works fine. Though CPU utilization is almost 90% and 100
> simultaneous threads created for 100 simultaneous threads.
>
> Both my server and clients are on Linux 64 bit machines.
>
> I believe that this is something related to the client 1 i.e.
> either the HTTPClient 3.1 or the MultiThreadedConnectionManager,but
> posting here if someone can assist me in what might be the root
> cause.
Try a single thread and a single connection. Take a packet-capture and
see what the response headers look like. I wouldn't be surprised if
you are generating a new session with each and every request.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRuIlpAAoJEBzwKT+lPKRYjo4P/2S+89ycBzPTnxonur/aTUxm
0ZIHWHsDbKlg7YRlMlvpcPGuyXniW9mDOw5wWajt4WSCmcWNDEfI3bIIAI139lkw
EeEFIVplkK/ZY2uLViJ0B4V9A/kBB7qkGDNPPubeNnhpi6gVGl+j3jB1S9aHOT9t
dmLGavG1j1pRtAUTItr1kVKAegyaYCSlwbDe8YQefRF8+N/DyAi3wutSdoOpGYMA
WytWWW4QvnFCZF3BcS13AhMgcPM/j81tQUtfnjLDIjV4KmAZwoF8i/4ZE21+Twl6
XfrFQve4DK+AhjGfqkobGKm1AlUycqI+8BGKbjEhtcOAmavfQDVtuV90Ahmb2gWd
9tNEf/EhQZuQcX5Gqg3WI7Ut7gz/9/f5i4P+1MN6AwwDTt7EJ0yl975+4eaziBaw
en53fE4mPIB71r5DrCIEJ2nNHWTz5bQTIuv58wMKRGtetxZbqjdOuaBY8Pnrw73b
kkPcQxgzA/CxWUxbKjnMuCHFz7eKAPaukytkSnIxWcqwftesNU2WvUgNsuhXpNnI
Bp4BxV+B669FTtlRZrlCj6U2+1SgJzgWy9ZH3IzANsgVs4nUmHROiD7ZM9HLU+8m
XnqOwcTcubG1eJq0vjYtpOs1hCsQwORTJS0CQhwH0WHVH3h+n9evnnkTAu0DB8++
yKwZFsmuD2oSjeLHOgWK
=FOAt
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, On 6/11/13 6:51 PM, Steve Nickels wrote: > I've been trying to compile tcnative on Windows with a > FIPS-compatible build of OpenSSL. I've been successful building > and running tcnative this way, at least until I turn on FIPS mode > on the AprLifecycleListener config in Tomcat. Note that tcnative/FIPS mode hasn't gotten a huge amount of testing. I'm glad we're getting some users of it. > When FIPSMode is set to "off", Tomcat works fine, and SSL services > operate correctly. When it is set to "on", however, Tomcat refuses > to start, and I get the following error in the catalina log file: > > SEVERE: Failed to initialize the SSLEngine. java.lang.Exception: > error:2D06B06F:FIPS > routines:FIPS_check_incore_fingerprint:fingerprint does not match That definitely seems like OpenSSL is refusing to start because it's failing its self-checks. > I'm fairly confident that the OpenSSL library I'm using is valid > and uncorrupted (I've used a couple different copies: an existing > set of binaries being used successfully in another product > internally, and a newly built version which I have successfully > used the openssl utility against, without error). Can you write a simple C program to link against OpenSSL and try to start it in FIPS mode? Does that work without error? Feel free to just steal code from tcnative to put-together a Frankenstein's monster of code just to see if it works. > My assumption is that I'm not building/linking OpenSSL correctly > into tcnative. ...and you are building tcnative by hand because the OpenSSL Tomcat provides is not build with FIPS compatibility, right? You will have to make sure you have a FIPS-compatible OpenSSL (please post the result of "openssl.exe version") and you will definitely have to re-build tcnative against it because otherwise all the FIPS stuff will generate errors before even trying to call FIPS_mode_set on OpenSSL. > So far I've tried building both the tcnative and libtcnative > projects via the supplied Visual Studio workspace. In the former > case, the APR library appears to statically linked into > tcnative-1.dll, so I don't have to provide libapr-1.dll, however I > do still need to provide libeay.dll and ssleay.dll. In the latter > case, I provide libtcnative-1.dll, libapr-1.dll, and the two > OpenSSL libraries. In both cases, it works when FIPS mode is off, > but not when it is on. > > Is there anything special I need to do to correctly build tcnative > to support a FIPS-compatible OpenSSL build with FIPSMode turned on > in Tomcat? > > All this is using Tomcat 7.0.32, tcnative 1.1.27, APR 1.4.6, and > OpenSSL both 1.0.1c and 1.0.1e, on 32-bit Windows Server 2008. Unfortunately, I have no experience building projects on Microsoft Windows... I was able to get the library built and successfully enabled FIPS mode on Linux (where I did my minimal testing). What does "openssl.exe version" currently print? I presume it advertises FIPS-mode? Given that you are getting an OpenSSL error message, it appears that you have built tcnative properly (that is, OPENSSL_FIPS has been detected and tcnative is actually attempting to enter FIPS mode). So I think something must be wrong with either the OpenSSL library itself or the linkage between the two. I notice that Tomcat distributes openssl.exe and not openssl.dll (or similar). Are you building openssl.exe or openssl.dll when you build OpenSSL? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuIdgAAoJEBzwKT+lPKRY+0MP/2ps/cZFddJPimCROpbYddsD YipUIsCyVMAQzD0LTYqSK+bpNq5sPu/hWLCrSZ77TO5yV9TveU/mK5bBPUkVUurk jZd8eitpup2c5wogULKm+OWyG24V4aGVt9YoQ3OPspNTmKoAsH7e71DbAzkUOC5r Mft4z3KTrWIFJeeog2HMc7CegesvpTMnZ9fUu92Y7ZUxmYAWSiedhEmYvXYUZXGr BYeAmb8G7Z+bFWNZ9Rd1yQ/N/NeVqxAuIPzNq89LzBGiE9be+AbMOIg6KitvuIUP aEHrH/KcKOxjd8Ey/j70+QJMaXdBfazSgjj68gQYtKABN/cv3gac8ckRgVMxgrLQ L2Y5LuHfkpLtAB2mcJ5yyQxcVXeBeqfYFXRrAnDKmlRL4fUYif6OGa8OC4Q2dKn7 m+wjjCsK6MyyQzJhBHUzMph1cVORhuLcs6sidqQU8Un5rkTJEgm4xrAA2KS/vhEk TG/exddFlCT0iYbuGhhm0McA+AxFybz8qP5ibz7iayVmnCmBzMGuOTsMkGjugkBh UaKYtnN3v98ovyCQVfw6lCAL2XV85NjsemIo3B1XYjJ7DZPO9GrTwKqbO1oDBbgl RaG/kFupohJPO79yg+mzxQrWt2kFPdGAA1DaceRKhHgSxzJC8cpoovnV3Wi2Bwnr 8lplxWIr7mZgrsSXZo9h =pJzS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http request (no only session) replication in cluster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jakob, On 6/11/13 5:04 PM, Ja kub wrote: > requirement is system should be possible to process 160 req/sec > (200 is better to multiply) and system is kind of failover proxy > itself > > there are 2 backing webservices, each can answer max 20s, it there > is timeout on first, I must call the second, if there is timeout on > second I send soap fault to client, so usually it shouldn't be more > than 20s per req, guys say that normally it is 7-10 > seconds/request, but in worst case it is 2*20s*160 requests/s ~= > 6400 pending requests (and according to deal we must fulfill worst > case) If you have 2 member nodes and one of them starts to slow down, then you'll see pretty much all requests re-tried on the second node, which will slow down that one. I think you'll end up seeing a storm of requests bouncing back and forth. Worse, the initial request will continue processing on the 1st node, ignorant of the fact that the lb has given up and tried the other node. It's just going to fall apart from there. Honestly, this should be able to be handled at your lb -- can't you set a time-out there? > even if there are so many requests they are pending on sockets, I > try to do it with NIO, asynchronous servlets and async cxf - both > async cxf webservice is exposed by me, and I also call backing ws > with async cxf I think even one tomcat on one server should be able > to serve such 6400 pending requests with 160req/s, apart from proxy > there are also 4-6 inserts into database (cli req, resp; 1st ws > call, resp; 2nd ws call, resp > > how do You assess such architecture/attitude ? do You expect > problems with async exposed webservice based on async servlet and > NIO, and async cxf ws client ? afaik cxf use thread locals, are > they all right with tomcat async servlets ? (I don't define > threadlocals by myself, only cxf possibly does) It's not a socket-resource issue, it's a raw work-load issue: you have a large amount of load and it looks like you can't handle it very well. I would recommend more nodes, first, and then seriously consider whether re-trying on a second node is appropriate if the first node takes too long. What you should probably do is actually profile your code to find out what is taking so long. Using tricks like ThreadLocals can shed microseconds off of a request, not whole seconds. You might want to consider whether you can do less work during a request -- perhaps split a single transaction into more than one. Or, just acknowledge that sometimes a transaction can take 10-20 seconds (or 50?) and manage the clients' expectations. You also need to find out where your bottleneck is: RDBMSs, slow disks, slow network links, etc. can all be much more significant than things like software stack and exact implementation of your code. If you are missing an index on a relational table, transactions that should take a second or two can take tens of seconds. Start there: profile your application, find out what is slow, and fix that. Don't try to work-around the problem with surprising transactional re-tries, because they likely won't work the way you hoped. Hey, once you fix your performance problem, perhaps you won't need additional hardware. Also, your users will be very happy to see a speed improvement. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuIFyAAoJEBzwKT+lPKRYr+4QAL7UCQvZ/CBIueIqhFDLkZ57 v0uWcuukEtT8/8dNUBW2SGSE4OwDyH41Nsx7ZVo4W+lTnzduVbjXSvU4lXNDiY19 9MgpwuxZWlUxHAgOQ5NODIFwrHQK2GYMe8+Qo8OBVf6lOhVdB4PS/7XM7lrsnWBn rpojl4rPm7+esciZPB1q15+PxCbgh4uGsI4KCXyZiW/gz/dLC2v8u6QiYfqoXgov iutYtII+7f1E6I+Ag3LjmQwrzY7pRpHrotcJ4aCpyOs9EHTavKf3mapwY2HiOP+t G9qwGuq5tUJhkBzF5Vdvqf+lCbdJHkQtLW3Z4vL4/XTK7SVSvjipFhsttZF4TII6 6QVQmjCJZRYdPDegzB+NVaCxPkdZLLdwHNFFfsZGabdTQDkAKOEXQiYjBqJ9n5nX WRHvYLQtyGEj1e+0zqwCihRHie2TbfwdggtCoVaOF+8Zpguv3K9VRHwvFA/miA1i JkYCfxKjyF/RoCyB4wZqCi5VsJjztQpq6uDQiUG0CACY1491sB35M+Vkqm3jqRbh 0HXs1ckqZsw+2Y013kpCVs0eipOst5GD6XqXr6LTT/fQwEYWa3uVTk3/h2xDd9BT DlTZrs1CNhqMBjNqUDUFkiiempf9kFkQhrao50CAilix95/VhdWkDjFcFSKKQ0/J EkcONNIioMTN7cWzKNHf =miI6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
Getting FIPS mode turned on and running is, unfortunately, far more complex than getting the libs, or even building them, and installing them. You need to follow the directions for building the FIPS module here: http://www.openssl.org/docs/fips/fipsnotes.html -and- http://www.openssl.org/docs/fips/UserGuide.pdf I've gone through this for OpenSSL 0.9 (FIPS 1.2), not for 2.0 and it is a process that takes a day at least, more likely two or three including collecting all the right tools. Keep in mind that you are trying to build an exact version of a library, not a functionally equivalent version. Things like compiler version make a difference. Basically, the process assures that the libs you build are validated as not having been changed since they were built and they were built from the unchanged source This involves a series of steps to validate everything from the downloaded source through to the finished lib. Unfortunately I don't have access to the libs I built, they could get you through testing. They would NOT be acceptable as genuinely FIPS compliant because you need to document the build process, including the signatures at each step, and keep that documentation. The error you are getting is expected because the lib you've built won't have the correct fingerprint (basically a hash of the lib) as compared to the known value. When you start FIPS mode, it runs validation on the loaded libraries. You'll probably notice a marked delay when it does start up correctly in FIPS mode.
RE: Class cast exception when starting tomcat 7.0.1
Oliver Tanglin | SAIC Software Appl. Engineer | C3 Systems and Analysis Division Phone: 703-676-7449 | Mobile: 727-207-1037 tangl...@saic.com -Original Message- From: users-return-242256-OLIVER.TANGLIN=saic@tomcat.apache.org on behalf of Jane Muse Sent: Tue 6/11/2013 7:42 PM To: users@tomcat.apache.org Subject: Class cast exception when starting tomcat 7.0.1 I'm getting a class cast exception when starting up tomcat 7.0.1. I've migrated from 6.0.18 to 7.0.1. I got the same error when migrating directly to 7.0.4. The error is: SEVERE: Begin event threw exception Throwable occurred: java.lang.ClassCastException: org.apache.catalina.deploy.SecurityConstraint incompatible with org.apache.catalina.deploy.SecurityConstraint at org.apache.catalina.startup.SetAuthConstraintRule.begin(WebRuleSet.java:745) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1282) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1543) at org.apache.catalina.startup.ContextConfig.parseWebXml(ContextConfig.java:1686) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1201) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:874) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:317) . . . Jun 11, 2013 2:17:07 PM org.apache.catalina.startup.ContextConfig parseWebXml SEVERE: Parse error in application web.xml file at jndi:/localhost/aldonsecurityservice/WEB-INF/web.xml Throwable occurred: java.lang.ClassCastException: org.apache.catalina.deploy.SecurityConstraint incompatible with org.apache.catalina.deploy.SecurityConstraint at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2687) at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2713) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1285) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) . . . . at java.lang.reflect.Method.invoke(Method.java:611) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:303) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431) Jun 11, 2013 2:17:07 PM org.apache.catalina.startup.ContextConfig parseWebXml SEVERE: Occurred at line 147 column 20 class load: java/util/LinkedHashMap$2 class load: java/util/LinkedHashMap$ValueIterator class load: org.apache.catalina.core.StandardWrapperFacade from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: org.apache.catalina.util.InstanceSupport from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: org.apache.catalina.InstanceListener from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: org.apache.catalina.core.StandardWrapperValve from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: javax.servlet.descriptor.TaglibDescriptor from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/servlet-api.jar Is it possible my XML parsers need updating. I'm still using the same ones in my WEB-INF/lib of the webapp: xalan.jar xerces.jar xerces-2.6.2.jar xml-apis.jar xmlrpc-1.2-b1.jar Thanks, JMuse Yes. The XML libraries you are using are notorious for this type of issue. Make sure you are compiling against the same ones provided with your instance of Tomcat. And do not include them in your WAR. For example, if you are using Maven, use provided in your element to filter them out when building your WAR. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.o
RE: Possible to expose a Tomcat Realm instance through JNDI ?
Thanks for the detail. As a final note and in case you are not already doing this, I have found the provided element in useful under similar circumstances when building a war. This prevents bundling of dependencies provided by the container such as catalina, servlet, etc. Regards, Oliver -Original Message- From: users-return-242264-OLIVER.TANGLIN=saic@tomcat.apache.org on behalf of Tobias Gierke Sent: Wed 6/12/2013 5:17 AM To: users@tomcat.apache.org Subject: Re: Possible to expose a Tomcat Realm instance through JNDI ? Hi, > Thanks for posting your results. > > But I am thinking now that this may lead to a portability issue. Push to a > container other than Tomcat and 'org.apache.catalina.User' will not be > available on the classpath. Yes, this is a portability issue. But to be honest, changing (assuming a reasonably big application) to a different Application server is almost as unlikely as migrating to a different database vendor. At least in the last 15 years I've never seen this happen ... YMMV though ;) > > Also, during development you are forced to include catalina as a dependency > to compile. Or are you somehow using reflection? Yes, I'm depending on the Tomcat API. We already had it as a dependency in a different sub-module because we're using a custom Realm implementation. Since it's a Maven build I only need to update the version number in the parent POM.xml when upgrading the Tomcat, so not much of a hassle there. Cheers, Tobias > > Oliver > > > > -Original Message- > From: users-return-242261-OLIVER.TANGLIN=saic@tomcat.apache.org on behalf > of Tobias Gierke > Sent: Wed 6/12/2013 2:12 AM > To: users@tomcat.apache.org > Subject: Re: Possible to expose a Tomcat Realm instance through JNDI ? > > Hi Oliver, >> I think I now understand your issue. I was faced with a similar problem and >> could not figure out how to get the roles of an authenticated user through >> the servlet API. >> >> It seems to only allow the question 'request.isUserInRole(role)'. But does >> not seem to provide a way to get a list of roles that the user is in. >> >> I used a kludge whereby I defined the valid roles in a context init >> parameter (bad duplication of effort). Then used >> 'request.isUserInRole(role)'. I did not think to cast the >> 'request.getUserPrincipal()' return value. >> >> Please post if your methodology works. >> >> Oliver >> > I ended up using WebserviceContext#getUserPrincipal() and downcasting it > to org.apache.catalina.User ; should probably also work with the plain > HttpServletRequest since WebserviceContext is just a wrapper. > > Cheers, > Tobias > > > - > 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: mod_jk worker activation not working anymore in 1.2.37?
I can confirm that the one liner patch fixes the problem for me as well. Due to "policies", I have problems to roll this into the productive environment, so a release would be highly welcome even if this is the only fix (so it seems to me). Cheers Martin On Tue, Jun 11, 2013 at 6:42 AM, Rainer Jung wrote: > On 11.06.2013 00:58, Martin Knoblauch wrote: > > Any plans when 1.2.38 will be released? > > Not really, but it is overdue. So IMO we should release it during the > next few weeks. > > Regards, > > Rainer > > > On Mon, Jun 10, 2013 at 10:20 PM, Rainer Jung >wrote: > > > >> On 10.06.2013 17:29, Konstantin Kolinko wrote: > >>> 2013/6/10 David Gubler : > Hi list, > > We have recently upgraded our Apache servers from Debian Squeeze to > >> Wheezy > (from Apache 2.2.16 with mod_jk 1.2.30 to Apache 2.2.22 with mod_jk > >> 1.2.37). > The Tomcat version hasn't changed (7.0.37). > > We often do rolling releases by disabling (DIS) some worker in > >> jkmanager, > waiting for a few minutes for most sessions to go away (we use sticky > sessions but not forced), upgrading it, and re-enabling it. This > worked > perfectly with mod_jk 1.2.30. The server is rather busy (order of > >> 100-200 > req/s going to tomcat). > > However, with mod_jk 1.2.37, the activation state behaves erratically. > >> Say I > disable worker1 on all apache servers via jkmanager. When I go back to > >> the > jkmanager overview screen, it still shows as active. I hit reload, now > >> it > shows as disabled. I can wait for a few seconds or minutes, reload, > and > suddenly it shows up as active again! It keeps switching back and > forth > between active and disabled if I reload often enough. Afterwards I > >> usually > have to set it to active a few times to make it stick there. This > >> happens on > all apache servers independently. > > And more worringly, the load on the worker does not decrease, not even > >> after > waiting for half an hour or longer (with 1.2.30, the load on a worker > decreased to about 5% after 5-10 minutes). > > When I set a worker to stopped, the activation state also switches > >> between > active and stopped, the load on the worker goes down slowly, but the > requests do not cease completely. With 1.2.30, I could set a worker to > stopped and it instantaneously received no more requests. > > Other than that, mod_jk behaves as expected (e.g. if I shut down one > of > >> the > tomcats, the requests go to the other; load balancing works fine in > >> normal > operation). > > I have stripped down our workers.properties to the bare minimum that > we > need, and the problem is still there: > > ps=/ > worker.list=loadbalancer,jkstatus > worker.jkstatus.type=status > > worker.loadbalancer.type=lb > worker.loadbalancer.sticky_session=true > worker.loadbalancer.balance_workers=worker1,worker2 > > worker.worker1.type=ajp13 > worker.worker1.host=WW.XX.YY.ZZ > worker.worker1.port=8009 > worker.worker1.connect_timeout=7 > worker.worker1.prepost_timeout=7 > worker.worker1.socket_timeout=70 > worker.worker1.connection_pool_timeout=70 > worker.worker1.connection_pool_size=200 > worker.worker1.retry_interval=1000 > worker.worker1.lbfactor=1 > > [same for worker2, only difference is the IP address] > > Rest of the configuration is Debian standard. Apache uses JkAutoAlias, > JkMount and a bunch of JkUnMounts, but nothing fancy. > > The changelog does not really give me any clues as to what change > could > cause this, and neither does the workers.properties documentation :( > > Does anyone have an idea what I could be doing wrong? > > >>> > >>> Looking at the current changelog, > >>> > >>> ... > >>> > >>> Fix status worker not updating parameters for all members. > >> (mturk) > >>> > >>> > >>> That is > >>> http://svn.apache.org/viewvc?view=revision&revision=1354021 > >> > >> Yes that should be it. > >> > >> If the OP compiles himself, just add the tiny patch > >> > >> > >> > http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_status.c?r1=1354021&r2=1354020&pathrev=1354021 > >> > >> to your mod_jk source before compiling. > >> > >> Regards, > >> > >> Rainer > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
Re: Possible to expose a Tomcat Realm instance through JNDI ?
Hi, Thanks for posting your results. But I am thinking now that this may lead to a portability issue. Push to a container other than Tomcat and 'org.apache.catalina.User' will not be available on the classpath. Yes, this is a portability issue. But to be honest, changing (assuming a reasonably big application) to a different Application server is almost as unlikely as migrating to a different database vendor. At least in the last 15 years I've never seen this happen ... YMMV though ;) Also, during development you are forced to include catalina as a dependency to compile. Or are you somehow using reflection? Yes, I'm depending on the Tomcat API. We already had it as a dependency in a different sub-module because we're using a custom Realm implementation. Since it's a Maven build I only need to update the version number in the parent POM.xml when upgrading the Tomcat, so not much of a hassle there. Cheers, Tobias Oliver -Original Message- From: users-return-242261-OLIVER.TANGLIN=saic@tomcat.apache.org on behalf of Tobias Gierke Sent: Wed 6/12/2013 2:12 AM To: users@tomcat.apache.org Subject: Re: Possible to expose a Tomcat Realm instance through JNDI ? Hi Oliver, I think I now understand your issue. I was faced with a similar problem and could not figure out how to get the roles of an authenticated user through the servlet API. It seems to only allow the question 'request.isUserInRole(role)'. But does not seem to provide a way to get a list of roles that the user is in. I used a kludge whereby I defined the valid roles in a context init parameter (bad duplication of effort). Then used 'request.isUserInRole(role)'. I did not think to cast the 'request.getUserPrincipal()' return value. Please post if your methodology works. Oliver I ended up using WebserviceContext#getUserPrincipal() and downcasting it to org.apache.catalina.User ; should probably also work with the plain HttpServletRequest since WebserviceContext is just a wrapper. Cheers, Tobias - 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: Possible to expose a Tomcat Realm instance through JNDI ?
Thanks for posting your results. But I am thinking now that this may lead to a portability issue. Push to a container other than Tomcat and 'org.apache.catalina.User' will not be available on the classpath. Also, during development you are forced to include catalina as a dependency to compile. Or are you somehow using reflection? Oliver -Original Message- From: users-return-242261-OLIVER.TANGLIN=saic@tomcat.apache.org on behalf of Tobias Gierke Sent: Wed 6/12/2013 2:12 AM To: users@tomcat.apache.org Subject: Re: Possible to expose a Tomcat Realm instance through JNDI ? Hi Oliver, > I think I now understand your issue. I was faced with a similar problem and > could not figure out how to get the roles of an authenticated user through > the servlet API. > > It seems to only allow the question 'request.isUserInRole(role)'. But does > not seem to provide a way to get a list of roles that the user is in. > > I used a kludge whereby I defined the valid roles in a context init parameter > (bad duplication of effort). Then used 'request.isUserInRole(role)'. I did > not think to cast the 'request.getUserPrincipal()' return value. > > Please post if your methodology works. > > Oliver > I ended up using WebserviceContext#getUserPrincipal() and downcasting it to org.apache.catalina.User ; should probably also work with the plain HttpServletRequest since WebserviceContext is just a wrapper. Cheers, Tobias - 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
