Re: parallel deployment: multiple applications responding
On 23/02/2012 06:51, Aristedes Maniatis wrote: We've been using parallel deployment for some time now with tomcat 7.0.25. For the most part the parallel deployment is a really nice idea, particularly because we don't have sessions serialised and clustered across all running instances. However, we've had mysterious problems for some time now where fixes we've applied to the application don't seem to work. We added some logging and have confirmed that some requests are still being served by the OLD instances of the application which are still deployed in the tomcat container but have an older version and therefore should not be responding. We might have two apps like this (using a format of YYMMDD and a two digit sequence): enrol##12022203.war enrol##12021503.war We would expect that requests would be served from only the newer application, but we find that requests continue to be served from the old, even though all the sessions to the old application are long dead. Just to confirm things we have another application which does not use sessions at all. It also has the same problem: requests are being served by the wrong application. In Tomcat Manager, the old application is still marked as running, but we thought this is just how it appears in the UI. Clearly there is something not right here. 1. Is this a known issue? We'd need to understand the root cause to answer that. The short version is that requests will only be routed to the old version if a request includes a session ID that references it. I'd suggest adding the session cookie to your access log. 2. Is there some way to get the old application to fully undeploy as soon as it has no live sessions? No. It is on the to do list. We have been thinking about writing an external application to poll using JMX and do this, but that's quite a bit of work. It would be nicer if this happened inside tomcat itself. Agreed. Patches welcome. 3. Is there some resource we might be hanging onto which is preventing the old application from properly stopping? Maybe. But that would be a separate issue. 4. Should the tomcat manager show the older apps as still running or should they be shown as stopped? running. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: parallel deployment: multiple applications responding
On 23/02/12 7:24 PM, Mark Thomas wrote: On 23/02/2012 06:51, Aristedes Maniatis wrote: We've been using parallel deployment for some time now with tomcat 7.0.25. For the most part the parallel deployment is a really nice idea, particularly because we don't have sessions serialised and clustered across all running instances. However, we've had mysterious problems for some time now where fixes we've applied to the application don't seem to work. We added some logging and have confirmed that some requests are still being served by the OLD instances of the application which are still deployed in the tomcat container but have an older version and therefore should not be responding. We might have two apps like this (using a format of YYMMDD and a two digit sequence): enrol##12022203.war enrol##12021503.war We would expect that requests would be served from only the newer application, but we find that requests continue to be served from the old, even though all the sessions to the old application are long dead. Just to confirm things we have another application which does not use sessions at all. It also has the same problem: requests are being served by the wrong application. In Tomcat Manager, the old application is still marked as running, but we thought this is just how it appears in the UI. Clearly there is something not right here. 1. Is this a known issue? We'd need to understand the root cause to answer that. The short version is that requests will only be routed to the old version if a request includes a session ID that references it. I'd suggest adding the session cookie to your access log. Given that we've definitely seen this happen with our sessionless application, I'm not sure that will help us much. For our other apps which have sessions, what happens if the incoming cookie references a session which has expired? Will the connection be simply handled by the new application? Is there some chance that the old application then creates a new valid session for that connection? What we did do is add a version to our log4j logger so that we could see which application was handling requests. We got quite a mixture of requests to the older sessionless application. 2. Is there some way to get the old application to fully undeploy as soon as it has no live sessions? No. It is on the to do list. Is there a task I can follow? I was unable to find one. We have been thinking about writing an external application to poll using JMX and do this, but that's quite a bit of work. It would be nicer if this happened inside tomcat itself. Agreed. Patches welcome. Sure. I understand, but I would not know where to begin with the tomcat codebase. I haven't even tried to read the source at this point. I assume we'd need to hook into some listener that detects when sessions are terminated and tell when they reach zero. That is maybe one line of code in the right place... or not :-) 3. Is there some resource we might be hanging onto which is preventing the old application from properly stopping? Maybe. But that would be a separate issue. I am just looking for solutions within the particular stack that we are using (tapestry/cayenne) to see if there was some reason why tomcat wasn't fully letting go of the older application. 4. Should the tomcat manager show the older apps as still running or should they be shown as stopped? running. It would be nice if it showed as disabled (to use the mod_jk terminology for an instance which is running but gets no new sessions). But that doesn't really affect our underlying problem: it would just make it easier to understand what is happening. Thanks for your time. Ari -- -- Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 with servlet 3.0 and EL 2.2
Hello everyone, i'm new to the mailing list and I have a doubt that probably someone already had. I need to adapt my tomcat 6 to run servlet 3.0 and el 2.2. I work in a company that's very resilient about changing anything in the main server, even if it is to make an upgrade from tomcat 6 to 7, and i'm trying to show them the tools that they are going to have in case of an upgrade, and right now I'm trying to show them the benefits of having tomcat 7 with JSF 2.0, but several tools of this language works better with el 2.2 and servlet 3.0 has anyone tried to do something like this before? André Fróes http://andrefroes.net76.net/
Threads Locking Monitors(61 Threads Locking)
Hello Team, I am analyzing thread dumps of tomcat and I can see there are around 61 threads locking monitors Below is the description of the thread which is locking on monitor. I do not understand what is causing this. Kindly someone explain the analysis of the below thread. ajp-8009-35 daemon prio=3 tid=0x000116c40800 nid=0x2cc in Object.wait() [0xfffed0c7f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xfffef379b3d0 (a org.apache.tomcat.util.net.AprEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.AprEndpoint$Worker.await(AprEndpoint.java:1511) - locked 0xfffef379b3d0 (a org.apache.tomcat.util.net.AprEndpoint$Worker) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1536) at java.lang.Thread.run(Thread.java:662)
Re: Tomcat 6 with servlet 3.0 and EL 2.2
On 23/02/2012 10:51, André Moraes wrote: Hello everyone, i'm new to the mailing list and I have a doubt that probably someone already had. I need to adapt my tomcat 6 to run servlet 3.0 and el 2.2. I work in a company that's very resilient about changing anything in the main server, even if it is to make an upgrade from tomcat 6 to 7, and i'm trying to show them the tools that they are going to have in case of an upgrade, and right now I'm trying to show them the benefits of having tomcat 7 with JSF 2.0, but several tools of this language works better with el 2.2 and servlet 3.0 Tomcat 6.0 implements Servlet 2.5. Tomcat 7.0 implements Servlet 3.0. If you want to use Servlet 3.0 etc features, then you'll need Tomcat 7.0. There is no way to use Tomcat 6.0 to achieve this. p has anyone tried to do something like this before? André Fróes http://andrefroes.net76.net/ -- [key:62590808] signature.asc Description: OpenPGP digital signature
RE: Threads Locking Monitors(61 Threads Locking)
From: Amol Puglia [mailto:amolcpug...@yahoo.com] Subject: Threads Locking Monitors(61 Threads Locking) I am analyzing thread dumps of tomcat What version? Below is the description of the thread which is locking on monitor. I do not understand what is causing this. The thread in question appears to be just waiting for a request to be given to it for processing. In other words, this is the normal state for an idle thread. (But without knowing the exact Tomcat version, it's impossible to be absolutely sure.) - 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
Form based Realm Authentication question
We're using Form based JNDIRealm Authentication against an LDAP server and it's all working fine except for one issue. When a user enters an invalid username/password they get sent to the error page, but they also get sent to the same error page if the LDAP server is down. Is there a way to trap the exception and redirect them to a different error page or, using a servlet as an error page, somehow pick up on the exception and display a slightly more specific error message like, Please contact the help desk. The authN server is unreachable.? Env: Tomcat 6.0.35. on Solaris, JDK 1.6.0_31. Thanks, Kris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Threads Locking Monitors(61 Threads Locking)
I am having tomcat version 6.0.26. Let me know if you need further information From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, February 23, 2012 7:44 PM Subject: RE: Threads Locking Monitors(61 Threads Locking) From: Amol Puglia [mailto:amolcpug...@yahoo.com] Subject: Threads Locking Monitors(61 Threads Locking) I am analyzing thread dumps of tomcat What version? Below is the description of the thread which is locking on monitor. I do not understand what is causing this. The thread in question appears to be just waiting for a request to be given to it for processing. In other words, this is the normal state for an idle thread. (But without knowing the exact Tomcat version, it's impossible to be absolutely sure.) - 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
Tomcat 7 Maven Plugin - embedded reload
I'm using the below Tomcat 7 Maven plugin and am not having any luck
reloading changed classes. Changes made to a jsp are reflected right away
but class file changes are not.
I have my IDE (Netbeans 7) set to compile on save, I'm using Maven 2.2.1
and I have reloadable='true' in my context.xml file.
I've not used Tomcat in years, and have never used it with Maven, so I'm
not really sure if the problem is with the plugin or Tomcat.
Can changed class files be reloaded without having to 'mvn tomcat7:run'
each time?
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
backgroundProcessorDelay5/backgroundProcessorDelay
contextFile${project.build.directory}/${project.build.finalName}/META-INF/context.xml/contextFile
/configuration
dependencies
dependency
groupIdcom.sybase/groupId
artifactIdjConnect/artifactId
version7.0.0/version
/dependency
dependency
groupIdcommons-fileupload/groupId
artifactIdcommons-fileupload/artifactId
version1.2.2/version
/dependency
/dependencies
/plugin
RE: ISAPI errors 87 when disabling IIS 7.0's response buffering
Hello Rainer, -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Monday, February 20, 2012 7:48 PM I don't really know, but 1220 is ERROR_CONNECTION_INVALID, which is closer to what you expected. One of the parameters passed to WriteClient and also in the vector write case is actually the connection ID so it could be that a unusable client connection could also return 87. Unfortunately MSDN doesn't have any useful information. Maybe Mladen or Tim know more about it. Regards, Rainer Thank you for your reply. I see that MSDN says about Winsock error 87: WSA_INVALID_PARAMETER - 87 One or more parameters are invalid. An application used a Windows Sockets function which directly maps to a Windows function. The Windows function is indicating a problem with one or more parameters. Note that this error is returned by the operating system, so the error number may change in future releases of Windows. So I guess the 87 errors correspond to the 1229 errors (when the connection is invalid). Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat with mod_jk becomes irresponsive after working for awhile
Caldarale, Charles R wrote: From: Ofer Israeli [mailto:of...@checkpoint.com] Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile I am in the situation where the server is giving 503s for all incoming requests, so I did a capture now to see what the situation is and as mentioned above I see Tomcat FINing the connections right away before mod_jk sends any content You might want to take a thread dump of Tomcat and see just what is going on. If all the threads are busy (or stuck), you may well have an application problem causing the 503. - Chuck Hi Chuck, I've taken a thread dump and haven't found anything that looks suspicious. What baffles me is that TaskManager shows that I have 580 threads in the Tomcat process (which makes sense since I use 500 worker threads for requests), but the thread dump only shows a small portion of these. Below is the dump, I'll be happy if you can give me some insight on this. 2012-02-23 20:08:16 Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode): Low Memory Detector daemon prio=6 tid=0x16bc7400 nid=0x2b38 runnable [0x] java.lang.Thread.State: RUNNABLE CompilerThread0 daemon prio=10 tid=0x16bbe400 nid=0x2828 waiting on condition [0x] java.lang.Thread.State: RUNNABLE Attach Listener daemon prio=10 tid=0x16bbcc00 nid=0xc4c runnable [0x] java.lang.Thread.State: RUNNABLE Signal Dispatcher daemon prio=10 tid=0x16bbb800 nid=0x1378 waiting on condition [0x] java.lang.Thread.State: RUNNABLE Finalizer daemon prio=8 tid=0x16baac00 nid=0x2f4c in Object.wait() [0x16d1f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x029f1158 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked 0x029f1158 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=10 tid=0x16ba6000 nid=0x2c5c in Object.wait() [0x16ccf000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x029f1058 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0x029f1058 (a java.lang.ref.Reference$Lock) main prio=6 tid=0x002a7c00 nid=0x2ecc runnable [0x0093f000] java.lang.Thread.State: RUNNABLE at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method) at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:82) at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:195) at sun.tools.attach.HotSpotVirtualMachine.remoteDataDump(HotSpotVirtualMachine.java:156) at sun.tools.jstack.JStack.runThreadDump(JStack.java:159) at sun.tools.jstack.JStack.main(JStack.java:94) VM Thread prio=10 tid=0x16ba2400 nid=0x320 runnable VM Periodic Task Thread prio=10 tid=0x16bcac00 nid=0x2cb4 waiting on condition JNI global references: 913 Heap def new generation total 4928K, used 756K [0x029f, 0x02f4, 0x07f4) eden space 4416K, 17% used [0x029f, 0x02aad0a0, 0x02e4) from space 512K, 0% used [0x02e4, 0x02e4, 0x02ec) to space 512K, 0% used [0x02ec, 0x02ec, 0x02f4) tenured generation total 10944K, used 0K [0x07f4, 0x089f, 0x129f) the space 10944K, 0% used [0x07f4, 0x07f4, 0x07f40200, 0x089f) compacting perm gen total 12288K, used 2379K [0x129f, 0x135f, 0x169f) the space 12288K, 19% used [0x129f, 0x12c42d68, 0x12c42e00, 0x135f) No shared spaces configured. Thanks, Ofer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat with mod_jk becomes irresponsive after working for awhile
Caldarale, Charles R wrote: From: Caldarale, Charles R Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile You might want to take a thread dump of Tomcat and see just what is going on. Also look in the Tomcat logs (there are several) to see if errors are being reported there. - Chuck Which logs are you referring to? I've turned on org.apache logs via log4j and haven't found anything related. Thanks, Ofer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat with mod_jk becomes irresponsive after working for awhile
Am 23.02.2012 19:32, schrieb Ofer Israeli: Caldarale, Charles R wrote: From: Ofer Israeli [mailto:of...@checkpoint.com] Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile I am in the situation where the server is giving 503s for all incoming requests, so I did a capture now to see what the situation is and as mentioned above I see Tomcat FINing the connections right away before mod_jk sends any content You might want to take a thread dump of Tomcat and see just what is going on. If all the threads are busy (or stuck), you may well have an application problem causing the 503. - Chuck Hi Chuck, I've taken a thread dump and haven't found anything that looks suspicious. What baffles me is that TaskManager shows that I have 580 threads in the Tomcat process (which makes sense since I use 500 worker threads for requests), but the thread dump only shows a small portion of these. Below is the dump, I'll be happy if you can give me some insight on this. 2012-02-23 20:08:16 Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode): Low Memory Detector daemon prio=6 tid=0x16bc7400 nid=0x2b38 runnable [0x] java.lang.Thread.State: RUNNABLE ... main prio=6 tid=0x002a7c00 nid=0x2ecc runnable [0x0093f000] java.lang.Thread.State: RUNNABLE at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method) at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:82) at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:195) at sun.tools.attach.HotSpotVirtualMachine.remoteDataDump(HotSpotVirtualMachine.java:156) at sun.tools.jstack.JStack.runThreadDump(JStack.java:159) at sun.tools.jstack.JStack.main(JStack.java:94) This is not a thread dump of tomcat, but rather jstack. Look at http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F for more info, to get a thread dump of tomcat. Regards Felix Thanks, Ofer - 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: Tomcat with mod_jk becomes irresponsive after working for awhile
Am 23.02.2012 19:32, schrieb Ofer Israeli: Caldarale, Charles R wrote: From: Caldarale, Charles R Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile You might want to take a thread dump of Tomcat and see just what is going on. Also look in the Tomcat logs (there are several) to see if errors are being reported there. - Chuck Which logs are you referring to? I've turned on org.apache logs via log4j and haven't found anything related. Normally they can be found under $CATALINA_BASE/logs. The most important ones are usually catalina.out and localhost*log. Regards Felix Thanks, Ofer - 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: Tomcat with mod_jk becomes irresponsive after working for awhile
Felix Schumacher wrote: Am 23.02.2012 19:32, schrieb Ofer Israeli: Caldarale, Charles R wrote: From: Ofer Israeli [mailto:of...@checkpoint.com] Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile I am in the situation where the server is giving 503s for all incoming requests, so I did a capture now to see what the situation is and as mentioned above I see Tomcat FINing the connections right away before mod_jk sends any content You might want to take a thread dump of Tomcat and see just what is going on. If all the threads are busy (or stuck), you may well have an application problem causing the 503. - Chuck Hi Chuck, I've taken a thread dump and haven't found anything that looks suspicious. What baffles me is that TaskManager shows that I have 580 threads in the Tomcat process (which makes sense since I use 500 worker threads for requests), but the thread dump only shows a small portion of these. Below is the dump, I'll be happy if you can give me some insight on this. 2012-02-23 20:08:16 Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode): Low Memory Detector daemon prio=6 tid=0x16bc7400 nid=0x2b38 runnable [0x] java.lang.Thread.State: RUNNABLE ... main prio=6 tid=0x002a7c00 nid=0x2ecc runnable [0x0093f000] java.lang.Thread.State: RUNNABLE at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method) at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:82) at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:195) at sun.tools.attach.HotSpotVirtualMachine.remoteDataDump(HotSpotVirtualMachine.java:156) at sun.tools.jstack.JStack.runThreadDump(JStack.java:159) at sun.tools.jstack.JStack.main(JStack.java:94) This is not a thread dump of tomcat, but rather jstack. Look at http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F for more info, to get a thread dump of tomcat. Regards Felix Hi Felix, I have seen that page but actually can't use the //MS// option as Tomcat is already running and in this bad state that I want to catch without restarting the service. Is there some way to gather this information without a restart? From what I understood jstack is supposed to give me all the JVM threads - am I missing something, can you elaborate on what it is I see there and why there are portions missing? Thanks, OFer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat with mod_jk becomes irresponsive after working for awhile
Felix Schumacher wrote: Am 23.02.2012 19:32, schrieb Ofer Israeli: Caldarale, Charles R wrote: From: Caldarale, Charles R Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile You might want to take a thread dump of Tomcat and see just what is going on. Also look in the Tomcat logs (there are several) to see if errors are being reported there. - Chuck Which logs are you referring to? I've turned on org.apache logs via log4j and haven't found anything related. Normally they can be found under $CATALINA_BASE/logs. The most important ones are usually catalina.out and localhost*log. Regards Felix I don't see these logs in the server. Could it be that this is due to Tomcat being embedded? Thanks, Ofer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LDAP connection issue
Am 22.02.2012 21:40, schrieb vbw:
Hi all,
I am having trouble using FORM based authentication against an LDAP
server.
I have configured my web.xml and server.xml and created a Login.jsp
page and can can successfully authenticate against a simple
tomcat-users.xml file. Therefore I am confident my basic
configurations are okay and my login page is good. Everything
behaves
as expected. Users are authenticated, authorized, errors are
forwarded appropriately, etc.
However, when I change my server.xml to use LDAP it appears that the
user credentials are not being sent to the LDAP server (Microsoft
Active Directory).
Here is the realm definition from the server.xml, which is defined
under the Catalina service (and is the only configured realm):
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
The debug attribute is not used in tomcat 6 or higher, so you can just
remove it :)
connectionName=myn...@mycompany.net
connectionPassword=mypassword
connectionURL=ldap://corp.mycompany.net:389;
userPattern=uid={0},ou='standard
users',ou=users,ou=mycompany,dc=corp,dc=mycompanycorp,dc=net
I believe you don't need the single ticks to protect your spaces there.
I don't know if they will harm, you could try to remove them.
roleBase=dc=corp,dc=mycompanycorp,dc=net
roleName=cn
roleSearch=memberUid={1}/
I do know that I am successfully binding to the LDAP server when
Tomcat starts. If I change mypassword to an invalid password then I
get a ConnectException due to the connection being refused. I also
see
So, we are editing the right context file, that is nice to know.
You could try to set logging for JNDIRealm to debug and see, what it
will tell you. Just add
org.apache.catalina.realm.JNDIRealm = FINE
to conf/logging.properties or whereever your tomcat installation has
its logging.properties file.
Regards
Felix
this connection using a network monitoring tool - it is initiated at
startup and then persists until Tomcat is shut down.
After the initial connection is made, I don't see any packets being
sent to the LDAP server. I've tried using both basic and form
authentication. Here's the web.xml snippet for form authentication:
security-constraint
web-resource-collection
web-resource-nameMyApplication/web-resource-name
url-pattern/Dashboard/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameRole1/role-name
role-nameRole2/role-name
/auth-constraint
/security-constraint
security-role
role-nameRole1/role-name
/security-role
security-role
role-nameRole2/role-name
/security-role
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/Login.jsp/form-login-page
form-error-page/Login.jsp?authError=login/form-error-page
/form-login-config
/login-config
I have spent hours researching and I can't see where I am going
wrong.
The LDAP connection, user and role information in the server.xml
seem
correct. However, no matter what I key in on the login page I get
back a 404 Page error - user is not authenticated.
I can't understand why I can connect to the LDAP server at server
startup but cannot authenticate users. Can anyone give me any ideas?
Any help would be much appreciated!
Thanks in advance,
Vaughne
-
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: Tomcat with mod_jk becomes irresponsive after working for awhile
Am 23.02.2012 19:50, schrieb Ofer Israeli: Felix Schumacher wrote: Am 23.02.2012 19:32, schrieb Ofer Israeli: Caldarale, Charles R wrote: From: Ofer Israeli [mailto:of...@checkpoint.com] Subject: RE: Tomcat with mod_jk becomes irresponsive after working for awhile I am in the situation where the server is giving 503s for all incoming requests, so I did a capture now to see what the situation is and as mentioned above I see Tomcat FINing the connections right away before mod_jk sends any content You might want to take a thread dump of Tomcat and see just what is going on. If all the threads are busy (or stuck), you may well have an application problem causing the 503. - Chuck Hi Chuck, I've taken a thread dump and haven't found anything that looks suspicious. What baffles me is that TaskManager shows that I have 580 threads in the Tomcat process (which makes sense since I use 500 worker threads for requests), but the thread dump only shows a small portion of these. Below is the dump, I'll be happy if you can give me some insight on this. 2012-02-23 20:08:16 Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode): Low Memory Detector daemon prio=6 tid=0x16bc7400 nid=0x2b38 runnable [0x] java.lang.Thread.State: RUNNABLE ... main prio=6 tid=0x002a7c00 nid=0x2ecc runnable [0x0093f000] java.lang.Thread.State: RUNNABLE at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method) at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:82) at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:195) at sun.tools.attach.HotSpotVirtualMachine.remoteDataDump(HotSpotVirtualMachine.java:156) at sun.tools.jstack.JStack.runThreadDump(JStack.java:159) at sun.tools.jstack.JStack.main(JStack.java:94) This is not a thread dump of tomcat, but rather jstack. Look at http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F for more info, to get a thread dump of tomcat. Regards Felix Hi Felix, I have seen that page but actually can't use the //MS// option as Tomcat is already running and in this bad state that I want to catch without restarting the service. Is there some way to gather this information without a restart? From what I understood jstack is supposed to give me all the JVM threads - am I missing something, can you elaborate on what it is I see there and why there are portions missing? Hi Ofer, I haven't used tomcat under windows, so I might be a bad adviser. Maybe you could use a tool like visualvm or jconsole from the jdk to attach to the running tomcat jvm and have a look at the threads. We will probably have to wait for windows users to help you. Regards Felix Thanks, OFer - 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
looks minSpareThreads is not honored - tc 7.0.25
Hi, I am using tomcat 7.0.25 on linux and java 6u30 to perform some load testing, and came to this observation. Performing some ab (apache benchmark) tests as specified in [1] and the http connector configured as: - references to an executor as Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=150 minSpareThreads=4/ - without an executor and with a minSpareThreads=15 in the connector - no minSpareThreads at connector and references to executor After 60s of the ab test, I see all request processor threads are terminated (reported by jstack PID or ps -p PID -o nlwp). But accordingly to the connector documentation The minimum number of threads always kept running. Is the connector docs wrong or is it a bug in the connector threading implementation ? Connector port=8080 protocol=HTTP/1.1 minSpareThreads=15 connectionTimeout=2 processorCache=150 redirectPort=8443 maxThreads=1024/ 1. ab -n 5 -c 1000 'http://localhost:8080/examples/servlets/servlet/SessionExample?dataname=foodatavalue=bar' -- View this message in context: http://tomcat.10.n6.nabble.com/looks-minSpareThreads-is-not-honored-tc-7-0-25-tp4500594p4500594.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Odd NIO connector behavior
Just a heads up to the Tomcat team - I switched all our comet handling to Jetty, and these issues are resolved. Something is definitely amiss in the NIO connector. Regards, Matt Tyson On Sat, Dec 31, 2011 at 10:23 AM, Mark Thomas ma...@apache.org wrote: On 31/12/2011 16:35, Matthew Tyson wrote: On Wed, Dec 28, 2011 at 1:04 AM, ma...@apache.org wrote: Matthew Tyson matthewcarlty...@gmail.com wrote: That's right, there is an f5 load balancer. The valve is used to keep track of whether the request was via HTTPS or not. What happens if you go direct to Tomcat and bypass the F5? tcpdump seems to confirm the same. What are you thinking? Probably, like me, that the F5 isn't handling the Comet requests correctly. Mark I am trying to understand how the load balancer could cause Tomcat to respond with an empty 200 response to a request, without ever executing the service method on the servlet mapped to the url. I've seen all sorts of odd behaviors when something is expecting HTTP but doesn't get it. The inbound request to tomcat is correct, and it is sometimes handled correctly. However, much of the time it is sending the empty 200. Given that there appears to be multiple issues here, I'd suggest concentrating on the one that is likely easiest to debug. Fix that and then see what the other problems then look like. We might be seeing two sides of the same issue. My recommendation is: - if possible, test without the F5 just to be sure this is purely a Tomcat issue - investigate the repeated calls to service() with no incoming request as that is likely to be easier to debug. As per my previous suggestion, get Tomcat into this state and then use remote debugging to see what is calling NioEndpoint.processSocket() Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
