Re: EXTERNAL: Re: Random file generation
On 16 August 2010 23:44, Miller, Kevin R kevin.r.mil...@lmco.com wrote: Any idea what this data is that is being sent to me? I'd expect it to be the start of the SSL negotiation. You're trying to do something unexpected, namely treating a SSL connection as if it wasn't one. Unsurprisingly, this doesn't work. - Peter
Re: Tomcat 7 - Anticipated date for a stable release?
On 16/08/2010 22:33, Theresa Robison wrote: Is there currently an anticipated date (or date range) for a stable release of Tomcat 7? My product would like to upgrade to the newest Tomcat release, but don't want to end up doing so twice in a short period of time... is it worthwhile to upgrade to Tomcat 6 for now, or will a stable release of Tomcat 7 be coming out shortly? Best guess would be Q4, but the more people using the beta the better as this will help discover any problems. p Thanks, Theresa Software Developer 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: WARNING: Error registering request
On 17/08/2010 06:41, VenkateswaraRao Eswar wrote: Could you please respond to this mail ASAP? This is a community driven list, the people who give their time are volunteers. You didn't respond to any of Chris's other points and you're insisting on staying with a Tomcat version that isn't supported any more. The ball's in your court, I'd say. p Thanks, Venkat --- On Tue, 10/8/10, VenkateswaraRao Eswar venkat_kudip...@yahoo.com wrote: From: VenkateswaraRao Eswar venkat_kudip...@yahoo.com Subject: Re: WARNING: Error registering request To: Tomcat Users List users@tomcat.apache.org Date: Tuesday, 10 August, 2010, 9:21 PM Thanks for your suggestions. Upgrading to newer versions is defenetely a good solution. But unfortunately, we are not looking to upgrade our production environment at this point of time. Any alternate solution to this issue with the current jdk/tomcat/Apache proxy versions instead of upgrading to newer versions? Thanks, Venkat --- On Fri, 6/8/10, Christopher Schultz ch...@christopherschultz.net wrote: From: Christopher Schultz ch...@christopherschultz.net Subject: Re: WARNING: Error registering request To: Tomcat Users List users@tomcat.apache.org Date: Friday, 6 August, 2010, 10:59 AM On 8/6/2010 5:20 AM, VenkateswaraRao Eswar wrote: With our production application, I am getting javax.management.InstanceAlreadyExistsException error messeges repeatedly before resulting in OutOfMemoryError. While I appreciate and agree with Mark's sentiments, it's always nice to have a production system that is working. How long has your application been in production? How long has this InstanceAlreadyExistsException - OutOfMemoryError condition been happening. Did anything change in your production configuration around the time that these errors started occurring? Generally speaking, these kinds of things don't just magically start to happen in a production system. Usually, one of the following things has occurred: 1. Someone tweaked some configuration and didn't properly test the effects 2. You released a new version of your web application and didn't properly test it The solution to the first problem is, of course, to reverse the configuration change and resume normal operations. The solution to the second problem is probably to downgrade your wep application, and re-think your next steps. Once you get your production system back up and running, you can concentrate on Mark's suggestions, which are, specifically: 1. Upgrade to a supported version of Java (which would be 1.6.x). This is perhaps the easiest thing you can possibly do, since the APIs are (in theory, anyway) backward compatible. The most noticeable thing about the upgrade will be better performance all around. 2. Upgrade mod_jk2 to mod_jk (yes, it sounds like a downgrade but jk2 was abandoned because jk basically back-ported all the features of jk2). The current version is 1.2.30. You didn't say what type of OS you were on. If you're on *NIX, compile it yourself. If you're on Windows, download the binary from the Tomcat website. Configuration is not too bad, and we can help with that when you're ready to transition, if the documentation isn't clear. Reading the sample mod_jk.conf file that ships with mod_jk is very instructive, so do that before you come crying to us. 3. Upgrade Tomcat to a supported version. 6.0.29 would be best, though sometimes it's prudent to stay a few point-releases behind the latest, just in case some weird bug appears that affects you. Upgrading from 5.0 to 6.0 shouldn't be too painful: just remember that you shouldn't try to use your server.xml from your 5.0 install to go to 6.0. Instead, use the stock 6.0 server.xml as a basis, and see what changes you'll need to make. Again, this shouldn't be tough to do since Tomcat should be backward-compatible as long as you stick to the servlet specification's rules. Just remember that as Tomcat matures, it gets more strict about the servlet spec rules, so you might notice things that no longer work because you were relying on out-of-spec behavior. Resources: http://tomcat.apache.org/migration.html (I thought there was an upgrade or migration page on the Wiki, but it appears there is none... perhaps I should write one). Hope that helps, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: JNDI: LDAPv3 with StartTLS
On Mon, 16 Aug 2010 22:39:14 + (UTC), Igor Galić
i.ga...@brainsware.org wrote:
- Felix Schumacher felix.schumac...@internetallee.de wrote:
On Sun, 15 Aug 2010 21:33:09 + (UTC), Igor Galić
i.ga...@brainsware.org wrote:
- Felix Schumacher felix.schumac...@internetallee.de wrote:
Ok, my patch will not work, since new InitialDirContext(env) will
not
create a LdapContext, but a DirContext. You could try to change
new
InitialDirContext(env) into InitalLdapContext(env, null) as used
in
the
sun startssl example.
I have implemented a InitialContextFactory which does startTLS
internally.
That factory can be used with the standard JNDIRealm implementation.
Just
extend your original Realm with
Realm
...
contextFactory=dummy.LdapTlsContextFactory
...
/
Following your advise, I compiled the source (within the tree) and
extended
the configuration to this:
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=ldap://mail.brainsware.org:389/;
alternateURL=ldap://mail.esotericsystems.at:389;
commonRole=admin connectionName=uid=whatever
connectionPassword=securityisgreat.
userBase=ou=people,dc=brainsware,dc=org
userPattern=(uid={0})(postOfficeBox=internal_projects)
startTLS=true
contextFactory=org.apache.naming.factory.LdapTlsContextFactory
userSearch=(uid={0}) /
Either use the LdapTlsContextFactory, or the patched tomcat. Not both. I
would advise to use the factory, since you can use a supported tomcat.
I had attached a second java class to my last mail, which you can use to
test the connection to your ldap server without tomcat. You may have to
specify a java keystore with your trusted certs. You can do this by
specifying the java env variable
-Djavax.net.ssl.trustStore=PATH_TO_MY/truststore.jks. If you want to learn
more about the tls steps, you can specify -Djavax.net.debug=ssl.
The wireshark trace still looks the same.
But the stacktrace is now two:
INFO: Starting Servlet Engine: Apache Tomcat/6.0.0-dev
Aug 16, 2010 10:37:25 PM org.apache.catalina.realm.JNDIRealm open
WARNING: Exception performing authentication
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 13 -
confidentiality required]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3032)
at
com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at
com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:293)
at
com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at
com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at
com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at
javax.naming.ldap.InitialLdapContext.init(InitialLdapContext.java:134)
at
org.apache.naming.factory.LdapTlsContextFactory$ProxyLdapContext.init(LdapTlsContextFactory.java:31)
at
org.apache.naming.factory.LdapTlsContextFactory$ProxyLdapContext.init(LdapTlsContextFactory.java:25)
at
org.apache.naming.factory.LdapTlsContextFactory.getInitialContext(LdapTlsContextFactory.java:96)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at
javax.naming.ldap.InitialLdapContext.init(InitialLdapContext.java:134)
at org.apache.catalina.realm.JNDIRealm.open(JNDIRealm.java:1982)
at
org.apache.catalina.realm.JNDIRealm.start(JNDIRealm.java:2087)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1037)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at
org.apache.catalina.core.StandardService.start(StandardService.java:519)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
Tomcat hangs every few hours
Tomcat hangs ever few hours. In server.xml maxThreads are 300. In thread dump I observed every thread doing the same thing. In my code I sends sms to users by using HttpURLConnection. I am using this code for months I didn't get the problem earlier. For few days I am getting this problem consistently. Whenever tomcat hangs I takes the thread dump, every time it shows the same results. Here is my one of threads dump. this is common for all remaining threads. Somebody guide me to solve this problem. I am trying but unable to do this http-80-300 daemon prio=1 tid=0x76890ef0 nid=0x6bb6 runnable [0x6def..0x6def0db0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked 0xb1332658 (a java.io.BufferedInputStream) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983) - locked 0xb1332690 (a sun.net.www.protocol.http.HttpURLConnection) at SendSms.sendToSingleRecipientNoNpri(SendSms.java:89) at CreateAccountAction.execute(CreateAccountAction.java:86) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.amulyam.servlet.RedirectFilter.doFilter(RedirectFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595)
RE: Tomcat Thread BLOCKED due to JDBC getConnection
Hi All, Kindly help me to resolve an issue in our production system, where tomcat is frequenctly getting hunged and axis request threads are been in BLOCKED state. Below is the snaphot of jstack during hunged state. Tomcat : 5.5 MySQL : 5 === jstack 12243 === Attaching to process ID 12243, please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.5.0_05-b05 Thread 7767: (state = IN_NATIVE) - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise) - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 (Compiled frame) - java.io.BufferedInputStream.fill() @bci=175, line=218 (Interpreted frame) - java.io.BufferedInputStream.read() @bci=12, line=235 (Interpreted frame) - java.io.FilterInputStream.read() @bci=4, line=66 (Interpreted frame) - sun.rmi.transport.tcp.TCPTransport.handleMessages(sun.rmi.transport.Connection, boolean) @bci=25, line=442 (Interpreted frame) - sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() @bci=685, line=701 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame) Thread 2102: (state = BLOCKED) - java.sql.DriverManager.getConnection(java.lang.String, java.lang.String, java.lang.String) @bci=0, line=158 (Interpreted frame) - com.zt.ebiz.util.DBUtil.getUnpooledConnection(java.lang.String, java.lang.String, java.lang.String, java.lang.String) @bci=15, line=465 (Interpreted frame) - com.zt.ebiz.util.DBUtil.getConnection(java.lang.String, java.lang.String, long, java.lang.String, java.lang.String, java.lang.String, boolean) @bci=123, line=351 (Interpreted frame) - com.zt.ebiz.handler.RTHandler.updateRTSchedule(long, long, int, int, int, java.util.LinkedHashMap) @bci=570, line=875 (Compiled frame) - com.zt.ebiz.handler.RTHandler.publishRealTimeCampaign(com.zt.ebiz.server.Campaign, long, int, java.util.LinkedHashMap) @bci=263, line=158 (Interpreted frame) - com.zt.ebiz.core.EbizServer.publishRealTimeCampaign(java.lang.String, long, int, java.util.LinkedHashMap) @bci=29, line=6927 (Interpreted frame) - com.zt.ebiz.ws.realtime.RealTimeServiceSoapBindingImpl.sendEbizMail(java.lang.String, java.lang.String, java.lang.String, com.zt.ebiz.ws.profile.ProfileDTO) @bci=214, line=132 (Interpreted frame) - sun.reflect.GeneratedMethodAccessor67.invoke(java.lang.Object, java.lang.Object[]) @bci=68 (Interpreted frame) - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6, line=25 (Compiled frame) - org.apache.axis.providers.java.RPCProvider.invokeMethod(org.apache.axis.MessageContext, java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) @bci=4, line=397 (Interpreted frame) - org.apache.axis.providers.java.RPCProvider.processMessage(org.apache.axis.MessageContext, org.apache.axis.message.SOAPEnvelope, org.apache.axis.message.SOAPEnvelope, java.lang.Object) @bci=549, line=186 (Compiled frame) - org.apache.axis.providers.java.JavaProvider.invoke(org.apache.axis.MessageContext) @bci=248, line=323 (Interpreted frame) - org.apache.axis.strategies.InvocationStrategy.visit(org.apache.axis.Handler, org.apache.axis.MessageContext) @bci=2, line=32 (Interpreted frame) - org.apache.axis.SimpleChain.doVisiting(org.apache.axis.MessageContext, org.apache.axis.HandlerIterationStrategy) @bci=37, line=118 (Compiled frame) - org.apache.axis.SimpleChain.invoke(org.apache.axis.MessageContext) @bci=31, line=83 (Compiled frame) - org.apache.axis.handlers.soap.SOAPService.invoke(org.apache.axis.MessageContext) @bci=70, line=453 (Interpreted frame) - org.apache.axis.server.AxisServer.invoke(org.apache.axis.MessageContext) @bci=552, line=281 (Interpreted frame) - org.apache.axis.transport.http.AxisServlet.doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=450, line=699 (Compiled frame) - javax.servlet.http.HttpServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=139, line=709 (Interpreted frame) - org.apache.axis.transport.http.AxisServletBase.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=6, line=327 (Interpreted frame) - javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=30, line=802 (Interpreted frame) - org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=354, line=252 (Interpreted frame) - org.apache.catalina.core.ApplicationFilterChain.doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=101, line=173 (Interpreted frame) - org.apache.catalina.core.StandardWrapperValve.invoke(org.apache.catalina.connector.Request,
Re: Tomcat Thread BLOCKED due to JDBC getConnection
Post your JDBC code On Tue, Aug 17, 2010 at 4:23 PM, Sunil Sharma sunil.sharm...@hotmail.comwrote: Hi All, Kindly help me to resolve an issue in our production system, where tomcat is frequenctly getting hunged and axis request threads are been in BLOCKED state. Below is the snaphot of jstack during hunged state. Tomcat : 5.5 MySQL : 5 === jstack 12243 === Attaching to process ID 12243, please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.5.0_05-b05 Thread 7767: (state = IN_NATIVE) - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise) - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 (Compiled frame) - java.io.BufferedInputStream.fill() @bci=175, line=218 (Interpreted frame) - java.io.BufferedInputStream.read() @bci=12, line=235 (Interpreted frame) - java.io.FilterInputStream.read() @bci=4, line=66 (Interpreted frame) - sun.rmi.transport.tcp.TCPTransport.handleMessages(sun.rmi.transport.Connection, boolean) @bci=25, line=442 (Interpreted frame) - sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() @bci=685, line=701 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame) Thread 2102: (state = BLOCKED) - java.sql.DriverManager.getConnection(java.lang.String, java.lang.String, java.lang.String) @bci=0, line=158 (Interpreted frame) - com.zt.ebiz.util.DBUtil.getUnpooledConnection(java.lang.String, java.lang.String, java.lang.String, java.lang.String) @bci=15, line=465 (Interpreted frame) - com.zt.ebiz.util.DBUtil.getConnection(java.lang.String, java.lang.String, long, java.lang.String, java.lang.String, java.lang.String, boolean) @bci=123, line=351 (Interpreted frame) - com.zt.ebiz.handler.RTHandler.updateRTSchedule(long, long, int, int, int, java.util.LinkedHashMap) @bci=570, line=875 (Compiled frame) - com.zt.ebiz.handler.RTHandler.publishRealTimeCampaign(com.zt.ebiz.server.Campaign, long, int, java.util.LinkedHashMap) @bci=263, line=158 (Interpreted frame) - com.zt.ebiz.core.EbizServer.publishRealTimeCampaign(java.lang.String, long, int, java.util.LinkedHashMap) @bci=29, line=6927 (Interpreted frame) - com.zt.ebiz.ws.realtime.RealTimeServiceSoapBindingImpl.sendEbizMail(java.lang.String, java.lang.String, java.lang.String, com.zt.ebiz.ws.profile.ProfileDTO) @bci=214, line=132 (Interpreted frame) - sun.reflect.GeneratedMethodAccessor67.invoke(java.lang.Object, java.lang.Object[]) @bci=68 (Interpreted frame) - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6, line=25 (Compiled frame) - org.apache.axis.providers.java.RPCProvider.invokeMethod(org.apache.axis.MessageContext, java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) @bci=4, line=397 (Interpreted frame) - org.apache.axis.providers.java.RPCProvider.processMessage(org.apache.axis.MessageContext, org.apache.axis.message.SOAPEnvelope, org.apache.axis.message.SOAPEnvelope, java.lang.Object) @bci=549, line=186 (Compiled frame) - org.apache.axis.providers.java.JavaProvider.invoke(org.apache.axis.MessageContext) @bci=248, line=323 (Interpreted frame) - org.apache.axis.strategies.InvocationStrategy.visit(org.apache.axis.Handler, org.apache.axis.MessageContext) @bci=2, line=32 (Interpreted frame) - org.apache.axis.SimpleChain.doVisiting(org.apache.axis.MessageContext, org.apache.axis.HandlerIterationStrategy) @bci=37, line=118 (Compiled frame) - org.apache.axis.SimpleChain.invoke(org.apache.axis.MessageContext) @bci=31, line=83 (Compiled frame) - org.apache.axis.handlers.soap.SOAPService.invoke(org.apache.axis.MessageContext) @bci=70, line=453 (Interpreted frame) - org.apache.axis.server.AxisServer.invoke(org.apache.axis.MessageContext) @bci=552, line=281 (Interpreted frame) - org.apache.axis.transport.http.AxisServlet.doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=450, line=699 (Compiled frame) - javax.servlet.http.HttpServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=139, line=709 (Interpreted frame) - org.apache.axis.transport.http.AxisServletBase.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=6, line=327 (Interpreted frame) - javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=30, line=802 (Interpreted frame) - org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=354, line=252 (Interpreted frame) - org.apache.catalina.core.ApplicationFilterChain.doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=101, line=173
[OT] Re: Tomcat hangs every few hours
On 17 August 2010 10:48, sasidhar prabhakar sasidhar1...@gmail.com wrote: In thread dump I observed every thread doing the same thing. In my code I sends sms to users by using HttpURLConnection. I am using this code for months I didn't get the problem earlier. For few days I am getting this problem consistently. Whenever tomcat hangs I takes the thread dump, every time it shows the same results. Here is my one of threads dump. this is common for all remaining threads. Somebody guide me to solve this problem. I am trying but unable to do this http-80-300 daemon prio=1 tid=0x76890ef0 nid=0x6bb6 runnable [0x6def..0x6def0db0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) [...] at SendSms.sendToSingleRecipientNoNpri(SendSms.java:89) [...] The socket is hanging trying to read the response. Your SMS provider probably isn't responding to you on occasion. I assume you've written test code to do a SMS send; if not, write it and test the SMS send outside of Tomcat. This is not a Tomcat issue, so I've marked it [OT]. - Peter
Re: WARNING: Error registering request
On 17 August 2010 06:41, VenkateswaraRao Eswar venkat_kudip...@yahoo.comwrote: Could you please respond to this mail ASAP? That's a very good way of making sure the volunteers on this list *never* respond to your email. You are not paying for this support. There is no service level agreement. If you want support that responds in a fixed time - or at all - then buy some. - Peter
Re: Tomcat hangs every few hours
Hi, One obvious possibility is that your SMS gateway (or your connection to it) is down - thus all threads are being 'blocked' waiting for a response from the gateway. This is supported by the fact that the threads are all blcoked in the socketRead0 call. Can I suggest, if you haven't already, to ensure you set a connect timeout and a 'wait' timeout (i.e. only wait x ms or secs before terminating the request and signalling a failure). I'm not sure what the default socket connect and read/write timeouts in Java are (they may be forever) but if they default to the OS level timeouts then they can be as much as 15 minutes (5 minutes + 3x retry). Hope this helps On Tue, 2010-08-17 at 15:18 +0530, sasidhar prabhakar wrote: Tomcat hangs ever few hours. In server.xml maxThreads are 300. In thread dump I observed every thread doing the same thing. In my code I sends sms to users by using HttpURLConnection. I am using this code for months I didn't get the problem earlier. For few days I am getting this problem consistently. Whenever tomcat hangs I takes the thread dump, every time it shows the same results. Here is my one of threads dump. this is common for all remaining threads. Somebody guide me to solve this problem. I am trying but unable to do this http-80-300 daemon prio=1 tid=0x76890ef0 nid=0x6bb6 runnable [0x6def..0x6def0db0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked 0xb1332658 (a java.io.BufferedInputStream) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983) - locked 0xb1332690 (a sun.net.www.protocol.http.HttpURLConnection) at SendSms.sendToSingleRecipientNoNpri(SendSms.java:89) at CreateAccountAction.execute(CreateAccountAction.java:86) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.amulyam.servlet.RedirectFilter.doFilter(RedirectFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595) -- Best Regards, Brett Delle Grazie __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat hangs every few hours
On 17/08/2010 10:48, sasidhar prabhakar wrote: Tomcat hangs ever few hours. *Exact* Tomcat, JVM and OS versions? In server.xml maxThreads are 300. In thread dump I observed every thread doing the same thing. In my code I sends sms to users by using HttpURLConnection. I am using this code for months I didn't get the problem earlier. For few days I am getting this problem consistently. Whenever tomcat hangs I takes the thread dump, every time it shows the same results. Here is my one of threads dump. this is common for all remaining threads. Somebody guide me to solve this problem. I am trying but unable to do this If each request processor thread is dependent on an inline request to an external resource, and that resource is unavailable or otherwise slow to respond then your app will inevitably run out of threads. You should consider offloading the request to a thread pool (see the Java Concurrency API in recent JVMs) with appropriate timeouts. p http-80-300 daemon prio=1 tid=0x76890ef0 nid=0x6bb6 runnable [0x6def..0x6def0db0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked 0xb1332658 (a java.io.BufferedInputStream) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983) - locked 0xb1332690 (a sun.net.www.protocol.http.HttpURLConnection) at SendSms.sendToSingleRecipientNoNpri(SendSms.java:89) at CreateAccountAction.execute(CreateAccountAction.java:86) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.amulyam.servlet.RedirectFilter.doFilter(RedirectFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595) 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Destroying Context Listeners
On 16/08/2010 18:32, CRANFORD, CHRIS wrote: I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7 (Win64) and I am actively testing our current web applications for backward compatibility, and so forth. One of these web applications creates a set of context listeners to manage various things during the lifecycle of the web application. During the startup of the web app, I do see that the contextInitialized() method is called; however when either Tomcat is stopped or restarted whether from the command line or via MyEclipse 8.6; I do not see that contextDestroyed() is being invoked. This is causing some heartburn on our end with this particular web app and I cannot find any solution. Has anyone seen this and/or is this confirmed as a problem with Tomcat 7? Or is there another expectation under Servlet 3.0 that I may have overlooked. Which exact version of Tomcat 7.0? Are you able to consistently reproduce this? What means are you using to determine that contextDestroyed() is not called? Log messages or... ? p Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: Destroying Context Listeners
When I check the version of Tomcat 7, it says it is 7.0.0.0. It's the compiled version from 6/13/2010. And yes, the log calls in the destroy method are never done, hence my concern that it isn't being invoked. Under Tomcat 6, these log messages were captured and written indicating a successful execution of the method. Even when I use a simple context listener that does a log message at startup and destroy times, only the startup one is captured. Chris -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Tuesday, August 17, 2010 7:47 AM To: Tomcat Users List Subject: Re: Destroying Context Listeners On 16/08/2010 18:32, CRANFORD, CHRIS wrote: I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7 (Win64) and I am actively testing our current web applications for backward compatibility, and so forth. One of these web applications creates a set of context listeners to manage various things during the lifecycle of the web application. During the startup of the web app, I do see that the contextInitialized() method is called; however when either Tomcat is stopped or restarted whether from the command line or via MyEclipse 8.6; I do not see that contextDestroyed() is being invoked. This is causing some heartburn on our end with this particular web app and I cannot find any solution. Has anyone seen this and/or is this confirmed as a problem with Tomcat 7? Or is there another expectation under Servlet 3.0 that I may have overlooked. Which exact version of Tomcat 7.0? Are you able to consistently reproduce this? What means are you using to determine that contextDestroyed() is not called? Log messages or... ? p 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: Tomcat Thread BLOCKED due to JDBC getConnection
From: Sunil Sharma [mailto:sunil.sharm...@hotmail.com] Subject: RE: Tomcat Thread BLOCKED due to JDBC getConnection Kindly help me to resolve an issue in our production system, where tomcat is frequenctly getting hunged and axis request threads are been in BLOCKED state. Below is the snaphot of jstack during hunged state. Note that other than the request dispatching, there's no Tomcat code in the path that's hanging - Tomcat is not involved. You need to debug your code in these methods: com.zt.ebiz.util.DBUtil.getUnpooledConnection() com.zt.ebiz.util.DBUtil.getConnection() com.zt.ebiz.handler.RTHandler.updateRTSchedule() com.zt.ebiz.handler.RTHandler.publishRealTimeCampaign() com.zt.ebiz.core.EbizServer.publishRealTimeCampaign() com.zt.ebiz.ws.realtime.RealTimeServiceSoapBindingImpl.sendEbizMail() Nothing Tomcat can do to correct design or programming errors in your webapp (such as failing to use an appropriate timeout value when connecting to an external resource). - 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: WARNING: Error registering request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 8/17/2010 4:16 AM, Pid wrote: You didn't respond to any of Chris's other points +1 ;) That's exactly what I didn't bother to respond: Venkat ignored the crux of my post (which was, in fact, aimed at keeping him running in production with his current software versions) and focused on not upgrading. When I get what I need to help him (or her?), I'll be happy to help if I can. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqm70ACgkQ9CaO5/Lv0PBgbgCfZ2NRLR0NbBJeDG0iJpkhRzDt 0vsAn07vqJu1vfvR4TkAz0PetXmwi/Kz =gF63 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JNDI: LDAPv3 with StartTLS
Either use the LdapTlsContextFactory, or the patched tomcat. Not both.
I
would advise to use the factory, since you can use a supported
tomcat.
ACK. Done that. In a vanilla Tomcat, I've put your LdapTlsContextFactory in
jar in lib/ with a config such as this:
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=ldap://mail.brainsware.org:389;
alternateURL=ldap://mail.esotericsystems.at:389;
commonRole=admin connectionName=uid=whatever
connectionPassword=securityisgreat.
userBase=ou=people,dc=brainsware,dc=org
userPattern=(uid={0})(postOfficeBox=internal_projects)
contextFactory=tc.startTLS.LdapTlsContextFactory
userSearch=uid={0} /
On startup I see this:
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Aug 17, 2010 9:33:47 AM org.apache.catalina.realm.JNDIRealm open
WARNING: Exception performing authentication
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 13 -
confidentiality required]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3032)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:293)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at
com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at
com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at
javax.naming.ldap.InitialLdapContext.init(InitialLdapContext.java:134)
at
tc.startTLS.LdapTlsContextFactory$ProxyLdapContext.init(LdapTlsContextFactory.java:31)
at
tc.startTLS.LdapTlsContextFactory$ProxyLdapContext.init(LdapTlsContextFactory.java:25)
at
tc.startTLS.LdapTlsContextFactory.getInitialContext(LdapTlsContextFactory.java:96)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.init(InitialContext.java:197)
at
javax.naming.directory.InitialDirContext.init(InitialDirContext.java:82)
at org.apache.catalina.realm.JNDIRealm.open(JNDIRealm.java:1954)
at org.apache.catalina.realm.JNDIRealm.start(JNDIRealm.java:2045)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1037)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at
org.apache.catalina.core.StandardService.start(StandardService.java:519)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
But the interesting thing is, that I see this here on login attempt (it's
actually the
first time I've tried that in a long time now... so I don't know what the other
cases would
have brought us):
SEVERE: An exception or error occurred in the container during the request
processing
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.getAttributes(Unknown Source)
at
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123)
at
org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:1217)
at
org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:1269)
at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1186)
at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1058)
at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:947)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:259)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:454)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
Re: Destroying Context Listeners
On 17/08/2010 14:11, CRANFORD, CHRIS wrote: When I check the version of Tomcat 7, it says it is 7.0.0.0. It's the compiled version from 6/13/2010. Try downloading the latest beta, (or compile from trunk). http://people.apache.org/~markt/dev/tomcat-7/v7.0.2/bin/ And yes, the log calls in the destroy method are never done, hence my It might seem like a silly question, but it's not always guaranteed that someone is using log messages to determine a fault. Is the log call the very first statement in the method? What kind of logging is it? If it's a proper logging system and not a System.out.println call, can you try with the latter instead? p concern that it isn't being invoked. Under Tomcat 6, these log messages were captured and written indicating a successful execution of the method. Even when I use a simple context listener that does a log message at startup and destroy times, only the startup one is captured. Chris -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Tuesday, August 17, 2010 7:47 AM To: Tomcat Users List Subject: Re: Destroying Context Listeners On 16/08/2010 18:32, CRANFORD, CHRIS wrote: I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7 (Win64) and I am actively testing our current web applications for backward compatibility, and so forth. One of these web applications creates a set of context listeners to manage various things during the lifecycle of the web application. During the startup of the web app, I do see that the contextInitialized() method is called; however when either Tomcat is stopped or restarted whether from the command line or via MyEclipse 8.6; I do not see that contextDestroyed() is being invoked. This is causing some heartburn on our end with this particular web app and I cannot find any solution. Has anyone seen this and/or is this confirmed as a problem with Tomcat 7? Or is there another expectation under Servlet 3.0 that I may have overlooked. Which exact version of Tomcat 7.0? Are you able to consistently reproduce this? What means are you using to determine that contextDestroyed() is not called? Log messages or... ? p 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 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Unable to get any information why jsp page fails to generate code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kannan, On 8/17/2010 12:22 AM, Kannan Jayaprakasam wrote: Any ideas? Try catching all exceptions and writing them to stdout or something. Is errorPage.html actually a JSP? If you'll notice, the original exception is java.lang.Exception (which isn't detailed) and then the stack trace describes the java.lang.IllegalStateException. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqprsACgkQ9CaO5/Lv0PC3kQCffwWWfpyLgZBhGcicVpbEo6Sx zCEAnjceVrPHPdrzm4gUNQcSG9Erxy3C =w4eY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Feedback Requested: Proposed CLI Tool for Apache Tomcat; kitty.
On 16/08/2010 21:06, Networked wrote: Elevator pitch Myself and Peary Chiu have created a lightweight utility for administering Tomcat from the command line in our copious amounts of free time on the weekends. This is a very rough utility, but we wanted a command line administration utility that made it very easy and quick to debug a Tomcat server via JMX. We are looking to solicit feedback from the community on this utility. Really it could be used for any application server, but because of Tomcat's relevance and our familiarity with it, we prefer to offer to this audience. The reason we are creating this utility is because we didn't feel that jconsole or other utilities such as jmxsh were not swift enough or user friendly enough for troubleshooting Tomcat in a production environment. We have nothing against these projects, we just had a different preference for this tool. Needs to be improved We are aware that it needs some features, such as: - #1 Documentation - Easier navigation - Bash-style auto completion (if accomplished, could also benefit the Jython project) - Compile Jython code to Java classes We are working on getting these problems addressed. To our knowledge it works without issue with Jython 2.5.1+. (http://sourceforge.net/projects/jython/files/) What we'd appreciate Feel free to reply back with bugs and enhancement requests. We believe this will eventually be a useful, lightweight administration utility for Tomcat. We believe that by putting this out to the community early, we can address the needs of the community for such a utility, if at all, and have the community give some feedback on their general thoughts on the project. Fin Code is available at: http://github.com/msacks/kitty Hi, I have some interest in this type of thing: am working on a pure Java CLI, but it's probably more simple than this looks. I'll give yours a whirl this evening. p Thanks for your friendly replies, Matthew Sacks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: Destroying Context Listeners
Pid -
I will download the latest beta and give it a try. When I realized what
was going on, I simply commented out all the logic I had in the two
methods and replaced them with the following:
public void contextDestroyed(ServletContextEvent arg) {
System.out.println(webapp listener context was destroyed.);
log.debug(contextDestroyed invoked successfully.);
}
public void contextInitialized(ServletContextEvent arg) {
System.out.println(webapp listener context was initialized.);
log.debug(contextInitialized invoked successfully.);
}
In my case, I saw the log entries for the initialization, but never for
destroy.
After I update to 7.0.2, I'll retest and let you know.
Chris
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Tuesday, August 17, 2010 10:07 AM
To: Tomcat Users List
Subject: Re: Destroying Context Listeners
On 17/08/2010 14:11, CRANFORD, CHRIS wrote:
When I check the version of Tomcat 7, it says it is 7.0.0.0.
It's the compiled version from 6/13/2010.
Try downloading the latest beta, (or compile from trunk).
http://people.apache.org/~markt/dev/tomcat-7/v7.0.2/bin/
And yes, the log calls in the destroy method are never done, hence
my
It might seem like a silly question, but it's not always guaranteed
that
someone is using log messages to determine a fault.
Is the log call the very first statement in the method?
What kind of logging is it? If it's a proper logging system and not a
System.out.println call, can you try with the latter instead?
p
concern that it isn't being invoked. Under Tomcat 6, these log
messages
were captured and written indicating a successful execution of the
method. Even when I use a simple context listener that does a log
message at startup and destroy times, only the startup one is
captured.
Chris
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Tuesday, August 17, 2010 7:47 AM
To: Tomcat Users List
Subject: Re: Destroying Context Listeners
On 16/08/2010 18:32, CRANFORD, CHRIS wrote:
I recently upgraded my Tomcat installation from 6.0.x to Tomcat 7
(Win64) and I am actively testing our current web applications for
backward compatibility, and so forth. One of these web
applications
creates a set of context listeners to manage various things during
the
lifecycle of the web application.
During the startup of the web app, I do see that the
contextInitialized() method is called; however when either Tomcat
is
stopped or restarted whether from the command line or via
MyEclipse
8.6;
I do not see that contextDestroyed() is being invoked. This is
causing
some heartburn on our end with this particular web app and I
cannot
find
any solution.
Has anyone seen this and/or is this confirmed as a problem with
Tomcat
7?
Or is there another expectation under Servlet 3.0 that I may have
overlooked.
Which exact version of Tomcat 7.0?
Are you able to consistently reproduce this?
What means are you using to determine that contextDestroyed() is
not
called? Log messages or... ?
p
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
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Destroying Context Listeners
Upgrading to 7.0.2 resolved the issue, thanks!
-Original Message-
From: CRANFORD, CHRIS [mailto:chris.cranf...@setech.com]
Sent: Tuesday, August 17, 2010 10:23 AM
To: Tomcat Users List
Subject: RE: Destroying Context Listeners
Pid -
I will download the latest beta and give it a try. When I realized
what
was going on, I simply commented out all the logic I had in the two
methods and replaced them with the following:
public void contextDestroyed(ServletContextEvent arg) {
System.out.println(webapp listener context was destroyed.);
log.debug(contextDestroyed invoked successfully.);
}
public void contextInitialized(ServletContextEvent arg) {
System.out.println(webapp listener context was initialized.);
log.debug(contextInitialized invoked successfully.);
}
In my case, I saw the log entries for the initialization, but never
for
destroy.
After I update to 7.0.2, I'll retest and let you know.
Chris
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Tuesday, August 17, 2010 10:07 AM
To: Tomcat Users List
Subject: Re: Destroying Context Listeners
On 17/08/2010 14:11, CRANFORD, CHRIS wrote:
When I check the version of Tomcat 7, it says it is 7.0.0.0.
It's the compiled version from 6/13/2010.
Try downloading the latest beta, (or compile from trunk).
http://people.apache.org/~markt/dev/tomcat-7/v7.0.2/bin/
And yes, the log calls in the destroy method are never done, hence
my
It might seem like a silly question, but it's not always guaranteed
that
someone is using log messages to determine a fault.
Is the log call the very first statement in the method?
What kind of logging is it? If it's a proper logging system and not
a
System.out.println call, can you try with the latter instead?
p
concern that it isn't being invoked. Under Tomcat 6, these log
messages
were captured and written indicating a successful execution of the
method. Even when I use a simple context listener that does a log
message at startup and destroy times, only the startup one is
captured.
Chris
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Tuesday, August 17, 2010 7:47 AM
To: Tomcat Users List
Subject: Re: Destroying Context Listeners
On 16/08/2010 18:32, CRANFORD, CHRIS wrote:
I recently upgraded my Tomcat installation from 6.0.x to Tomcat
7
(Win64) and I am actively testing our current web applications
for
backward compatibility, and so forth. One of these web
applications
creates a set of context listeners to manage various things
during
the
lifecycle of the web application.
During the startup of the web app, I do see that the
contextInitialized() method is called; however when either
Tomcat
is
stopped or restarted whether from the command line or via
MyEclipse
8.6;
I do not see that contextDestroyed() is being invoked. This is
causing
some heartburn on our end with this particular web app and I
cannot
find
any solution.
Has anyone seen this and/or is this confirmed as a problem with
Tomcat
7?
Or is there another expectation under Servlet 3.0 that I may
have
overlooked.
Which exact version of Tomcat 7.0?
Are you able to consistently reproduce this?
What means are you using to determine that contextDestroyed() is
not
called? Log messages or... ?
p
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
-
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: [OT] Re: Tomcat hangs every few hours
For months it is working properly. I tried that one also. Immediately after hangs I accessed the url directly several times it is working. Is that the only reason, I thought that but when accessed it is working. Is there any other reasons. On Tue, Aug 17, 2010 at 5:33 PM, Peter Crowther peter.crowt...@melandra.com wrote: On 17 August 2010 10:48, sasidhar prabhakar sasidhar1...@gmail.com wrote: In thread dump I observed every thread doing the same thing. In my code I sends sms to users by using HttpURLConnection. I am using this code for months I didn't get the problem earlier. For few days I am getting this problem consistently. Whenever tomcat hangs I takes the thread dump, every time it shows the same results. Here is my one of threads dump. this is common for all remaining threads. Somebody guide me to solve this problem. I am trying but unable to do this http-80-300 daemon prio=1 tid=0x76890ef0 nid=0x6bb6 runnable [0x6def..0x6def0db0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) [...] at SendSms.sendToSingleRecipientNoNpri(SendSms.java:89) [...] The socket is hanging trying to read the response. Your SMS provider probably isn't responding to you on occasion. I assume you've written test code to do a SMS send; if not, write it and test the SMS send outside of Tomcat. This is not a Tomcat issue, so I've marked it [OT]. - Peter
Re: Tomcat hangs every few hours
Thanks I will follow that On Tue, Aug 17, 2010 at 6:12 PM, Pid p...@pidster.com wrote: On 17/08/2010 10:48, sasidhar prabhakar wrote: Tomcat hangs ever few hours. *Exact* Tomcat, JVM and OS versions? In server.xml maxThreads are 300. In thread dump I observed every thread doing the same thing. In my code I sends sms to users by using HttpURLConnection. I am using this code for months I didn't get the problem earlier. For few days I am getting this problem consistently. Whenever tomcat hangs I takes the thread dump, every time it shows the same results. Here is my one of threads dump. this is common for all remaining threads. Somebody guide me to solve this problem. I am trying but unable to do this If each request processor thread is dependent on an inline request to an external resource, and that resource is unavailable or otherwise slow to respond then your app will inevitably run out of threads. You should consider offloading the request to a thread pool (see the Java Concurrency API in recent JVMs) with appropriate timeouts. p http-80-300 daemon prio=1 tid=0x76890ef0 nid=0x6bb6 runnable [0x6def..0x6def0db0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked 0xb1332658 (a java.io.BufferedInputStream) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983) - locked 0xb1332690 (a sun.net.www.protocol.http.HttpURLConnection) at SendSms.sendToSingleRecipientNoNpri(SendSms.java:89) at CreateAccountAction.execute(CreateAccountAction.java:86) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.amulyam.servlet.RedirectFilter.doFilter(RedirectFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595)
RE: [OT] Re: Tomcat hangs every few hours
From: sasidhar prabhakar [mailto:sasidhar1...@gmail.com] Subject: Re: [OT] Re: Tomcat hangs every few hours For months it is working properly. Then something must have changed, either on the Tomcat system, or the server your webapp is trying to communicate with. Try to find out what was altered. Is there any other reasons. Possible that the code in your webapp is not handling the responses it's getting from the mail server. Get Wireshark traces of the traffic between your webapp and the mail server and compare that with what the webapp is expecting. - 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: [OT] Re: Tomcat hangs every few hours
I don't know what wireshark is can we install it in production servers. If my webapp is not handling the responses what can I do. Could you please suggest that. On Tue, Aug 17, 2010 at 9:22 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: sasidhar prabhakar [mailto:sasidhar1...@gmail.com] Subject: Re: [OT] Re: Tomcat hangs every few hours For months it is working properly. Then something must have changed, either on the Tomcat system, or the server your webapp is trying to communicate with. Try to find out what was altered. Is there any other reasons. Possible that the code in your webapp is not handling the responses it's getting from the mail server. Get Wireshark traces of the traffic between your webapp and the mail server and compare that with what the webapp is expecting. - 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: [OT] Re: Tomcat hangs every few hours
From: sasidhar prabhakar [mailto:sasidhar1...@gmail.com] Subject: Re: [OT] Re: Tomcat hangs every few hours I don't know what wireshark is www.wireshark.org Equivalents are available for whatever platform you're running on. If my webapp is not handling the responses what can I do. Fix your webapp. - 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: JNDI: LDAPv3 with StartTLS
Am Dienstag, den 17.08.2010, 14:31 + schrieb Igor Galić:
Either use the LdapTlsContextFactory, or the patched tomcat. Not both.
I
would advise to use the factory, since you can use a supported
tomcat.
ACK. Done that. In a vanilla Tomcat, I've put your LdapTlsContextFactory in
jar in lib/ with a config such as this:
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=ldap://mail.brainsware.org:389;
alternateURL=ldap://mail.esotericsystems.at:389;
commonRole=admin connectionName=uid=whatever
connectionPassword=securityisgreat.
userBase=ou=people,dc=brainsware,dc=org
userPattern=(uid={0})(postOfficeBox=internal_projects)
contextFactory=tc.startTLS.LdapTlsContextFactory
userSearch=uid={0} /
That looks right. I believe I have found one issue with my code. It will
get a InitialDirContext with your admin user and password, before it is
negotiating TLS. I have attached another ContextFactory, which will
remove admin user, password and authentication method prior to TLS
negotiation. After (hopefully) establishing TLS it adds those parameters
back in. As with the last factory, you should select a package name of
your liking.
On startup I see this:
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Aug 17, 2010 9:33:47 AM org.apache.catalina.realm.JNDIRealm open
WARNING: Exception performing authentication
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 13 -
confidentiality required]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3032)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.init(LdapCtx.java:293)
at
com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at
com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at
com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at
javax.naming.ldap.InitialLdapContext.init(InitialLdapContext.java:134)
at
tc.startTLS.LdapTlsContextFactory$ProxyLdapContext.init(LdapTlsContextFactory.java:31)
this is just one line apart from startTLS :(
at
tc.startTLS.LdapTlsContextFactory$ProxyLdapContext.init(LdapTlsContextFactory.java:25)
at
tc.startTLS.LdapTlsContextFactory.getInitialContext(LdapTlsContextFactory.java:96)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
...
But the interesting thing is, that I see this here on login attempt (it's
actually the
first time I've tried that in a long time now... so I don't know what the
other cases would
have brought us):
SEVERE: An exception or error occurred in the container during the request
processing
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.getAttributes(Unknown Source)
at
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123)
I think this error is a result of the above stacktrace. The factory has
given us an object (proxy), which is not really useful. At least I hope
so.
I had attached a second java class to my last mail, which you can use
to
test the connection to your ldap server without tomcat. You may have
to
specify a java keystore with your trusted certs. You can do this by
specifying the java env variable
-Djavax.net.ssl.trustStore=PATH_TO_MY/truststore.jks. If you want to
learn
more about the tls steps, you can specify -Djavax.net.debug=ssl.
I haven't managed to get the TlsTest.java to compile.
Why?
Bye
Felix
The wireshark trace still looks the same.
Yep, still does.
i
package dummy;
import java.io.IOException;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Hashtable;
import java.util.Map;
import java.util.logging.Logger;
import javax.naming.Context;
import javax.naming.NamingException;
import javax.naming.directory.DirContext;
import javax.naming.ldap.InitialLdapContext;
import javax.naming.ldap.LdapContext;
import javax.naming.ldap.StartTlsRequest;
import javax.naming.ldap.StartTlsResponse;
import javax.naming.spi.InitialContextFactory;
import javax.net.ssl.HostnameVerifier;
import
Re: Feedback Requested: Proposed CLI Tool for Apache Tomcat; kitty.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew, On 8/16/2010 4:06 PM, Networked wrote: This is a very rough utility, but we wanted a command line administration utility that made it very easy and quick to debug a Tomcat server via JMX. Something like this? http://code.google.com/p/jmxsh/ - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxq9xsACgkQ9CaO5/Lv0PA9+QCgwA2l2lCoPrY2nUKZIgFtNBGJ oc4AnjD9M1FCteE35K+2o0o11Ax1zR72 =v8wb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JNDI: LDAPv3 with StartTLS
That looks right. I believe I have found one issue with my code. It will get a InitialDirContext with your admin user and password, before it is negotiating TLS. I have attached another ContextFactory, which will remove admin user, password and authentication method prior to TLS negotiation. After (hopefully) establishing TLS it adds those parameters back in. As with the last factory, you should select a package name of your liking. Done, now the startup looks all fine in the log -- but tshark speaks a different language: r...@iris ~ # tshark host 188.40.115.116 Running as user root and group root. This could be dangerous. Capturing on eth0 0.00 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=1189177744 TSER=0 WS=7 0.00 188.40.115.121 - 188.40.115.116 TCP ldap 42460 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=97730450 TSER=1189177744 WS=7 0.00 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=1189177744 TSER=97730450 0.004000 188.40.115.116 - 188.40.115.121 LDAP extendedReq(1) LDAP_START_TLS_OID 0.004000 188.40.115.121 - 188.40.115.116 TCP ldap 42460 [ACK] Seq=1 Ack=61 Win=5888 Len=0 TSV=97730451 TSER=1189177745 0.008000 188.40.115.121 - 188.40.115.116 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 0.008000 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [ACK] Seq=61 Ack=15 Win=5888 Len=0 TSV=1189177746 TSER=97730452 0.384000 188.40.115.116 - 188.40.115.121 SSLv2 Client Hello 0.384000 188.40.115.121 - 188.40.115.116 TLSv1 Server Hello, [Unreassembled Packet [incorrect TCP checksum]] 0.384000 188.40.115.121 - 188.40.115.116 TCP ldap 42460 [PSH, ACK] Seq=1463 Ack=161 Win=5888 [TCP CHECKSUM INCORRECT] Len=408 TSV=97730546 TSER=1189177839 0.384000 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [ACK] Seq=161 Ack=1463 Win=8832 Len=0 TSV=1189177839 TSER=97730546 0.384000 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [ACK] Seq=161 Ack=1871 Win=11648 Len=0 TSV=1189177839 TSER=97730546 0.408000 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [PSH, ACK] Seq=161 Ack=1871 Win=11648 Len=523 TSV=1189177846 TSER=97730546 0.448000 188.40.115.121 - 188.40.115.116 TCP ldap 42460 [ACK] Seq=1871 Ack=684 Win=6912 Len=0 TSV=97730562 TSER=1189177846 0.448000 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [PSH, ACK] Seq=684 Ack=1871 Win=11648 Len=43 TSV=1189177856 TSER=97730562 0.448000 188.40.115.121 - 188.40.115.116 TCP ldap 42460 [ACK] Seq=1871 Ack=727 Win=6912 Len=0 TSV=97730562 TSER=1189177856 0.448000 188.40.115.121 - 188.40.115.116 TCP ldap 42460 [PSH, ACK] Seq=1871 Ack=727 Win=6912 [TCP CHECKSUM INCORRECT] Len=43 TSV=97730562 TSER=1189177856 0.488000 188.40.115.116 - 188.40.115.121 TCP 42460 ldap [ACK] Seq=727 Ack=1914 Win=11648 Len=0 TSV=1189177866 TSER=97730562 This means: We are (disturbingly) sending an SSLv2 Hello, we get an TLSv1 reply, and now we're happy... Or so I blindly guess from the fact that no error or warning are logged.. I'm still trying to make sense of the ACK, ACK, PSH/ACK -- ACK -- ACK, PS/ACK. Anyway, then I try to login, and that's when this happens in the log: SEVERE: An exception or error occurred in the container during the request processing java.lang.reflect.UndeclaredThrowableException at $Proxy0.getAttributes(Unknown Source) at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123) at org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:1217) at org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:1269) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1186) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1058) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:947) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:259) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:454) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Feedback Requested: Proposed CLI Tool for Apache Tomcat; kitty.
Please see my original message. I mention jmxsh. On Tue, Aug 17, 2010 at 1:54 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew, On 8/16/2010 4:06 PM, Networked wrote: This is a very rough utility, but we wanted a command line administration utility that made it very easy and quick to debug a Tomcat server via JMX. Something like this? http://code.google.com/p/jmxsh/ - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxq9xsACgkQ9CaO5/Lv0PA9+QCgwA2l2lCoPrY2nUKZIgFtNBGJ oc4AnjD9M1FCteE35K+2o0o11Ax1zR72 =v8wb -END PGP SIGNATURE- - 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
Is there a better way to disable JSESSIONID in the URLs?
Using Tomcat 6.0.29, but I think this is version-independent (correct me if I'm wrong), at least for the 6.0.x versions. From what I understand (see http://randomcoder.com/articles/jsessionid-considered-harmful for instance - I also scanned various aspects of the tomcat source code) there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. The only way I've seen how to do this, as suggested on the site I referenced, is to put into place a servlet filter. I'd like to know if I'm missing anything - is there a better way to do this? We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out (especially when they demonstrate that you can get a URL from the app, email it to someone else, and have that person magically bypass authentication and assume the role of the other user - of course as long as the session is still valid). We are comfortable saying that in order to use our application you need to have cookies enabled, so I'm making the assumption that if we disable the feature of putting JSESSIONID into the URLs, either through a nice global switch or else a servlet filter, cookie-based session setting/tracking will still function just as we expect it. Finally, anyone know why this isn't already in the servlet spec? Seems like with more and more concern over web application security that this would be something the spec should address? Thanks, Scott . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited.
Re: Is there a better way to disable JSESSIONID in the URLs?
On Wed, Aug 18, 2010 at 12:01 AM, Scott Hamilton scott.hamil...@plateau.com wrote: Using Tomcat 6.0.29, but I think this is version-independent (correct me if I'm wrong), at least for the 6.0.x versions. From what I understand (see http://randomcoder.com/articles/jsessionid-considered-harmful for instance - I also scanned various aspects of the tomcat source code) there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. The only way I've seen how to do this, as suggested on the site I referenced, is to put into place a servlet filter. I'd like to know if I'm missing anything - is there a better way to do this? We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out (especially when they demonstrate that you can get a URL from the app, email it to someone else, and have that person magically bypass authentication and assume the role of the other user - of course as long as the session is still valid). We are comfortable saying that in order to use our application you need to have cookies enabled, so I'm making the assumption that if we disable the feature of putting JSESSIONID into the URLs, either through a nice global switch or else a servlet filter, cookie-based session setting/tracking will still function just as we expect it. Finally, anyone know why this isn't already in the servlet spec? Seems like with more and more concern over web application security that this would be something the spec should address? Thanks, Scott . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. I know of no better way to fix this. This is what we *had* to do to pass PCI too so its no small deal. However the filter does work wondefully with minimal overhead. Regards, Wesley Acheson - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: Is there a better way to disable JSESSIONID in the URLs? there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. - 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
All Threads Busy Message
Hello, I am using Tomcat 6.0.18 with JDK 1.6 with the JULI. I have enabled proper logging through the logging.properties. I am not seeing the 'All Threads Busy' error message when all the threads are in use or number of requests has exceeded the maxThreads and acceptCount values. I have set the following in the logging.properties file but I am not seeing the message. org.apache.tomcat.util.threads.level=FINEST org.apache.tomcat.util.threads.ThreadPool.level=FINEST I have confirmed Tomcat is seeing the logging.properties file by changing the logging levels of other packages. I am able to see the message in Tomcat 5.0 using log4j. -- View this message in context: http://old.nabble.com/All-Threads-Busy-Message-tp29449303p29449303.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: Is there a better way to disable JSESSIONID in the URLs?
Thanks for the reply. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. I could be missing something, but on a request where a session is created it appears as though Tomcat will both set the cookie AND do any necessary URL rewriting in order to ensure that the cookie is preserved. If the session (a) already exists and (b) was received in the request through a cookie reference it will NOT do the URL rewriting. I'm assuming this is to cover the bases and ensure a JSESSIONID gets injected into the following requests regardless of the client's cookie acceptance policy. And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. You're absolutely correct, and SSL is used for our security-conscious customers. The issue in question isn't so much about determined hackers but hapless users who will bookmark URLs or worse, copy URLs to email to their co-workers. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, August 17, 2010 6:16 PM To: Tomcat Users List Subject: RE: Is there a better way to disable JSESSIONID in the URLs? From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: Is there a better way to disable JSESSIONID in the URLs? there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. - 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 . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: All Threads Busy Message
From: JebaB [mailto:jebab...@yahoo.com] Subject: All Threads Busy Message I am using Tomcat 6.0.18 with JDK 1.6 with the JULI. Why such an old level? I am not seeing the 'All Threads Busy' error message when all the threads are in use or number of requests has exceeded the maxThreads and acceptCount values. Post your server.xml (without comments and with privileged information masked out) so we can see what the Connector elements look like. Note that if you're using an Executor, that message will never appear. - 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: Is there a better way to disable JSESSIONID in the URLs?
On 2010-08-17, at 18:15, Caldarale, Charles R chuck.caldar...@unisys.com wrote: Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. That's not true. Tomcat doesn't know if cookies are available until the second request, so the first page you get is full of URLs with jsessionids. Also search engine bots don't seem to use cookies. I saw lots of pointless re-re-re-crawling by search bots until I cleaned up the URLs. -- Len - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: RE: Is there a better way to disable JSESSIONID in the URLs? I could be missing something, but on a request where a session is created it appears as though Tomcat will both set the cookie AND do any necessary URL rewriting in order to ensure that the cookie is preserved. Sorry, you're right; at that point Tomcat doesn't know if the client supports cookies. However, when skimming through the Tomcat code, the only internal call to encodeURL() that I can find appears to be called only for relative URLs, so possibly making your initial URLs absolute might avoid appending the jsessionid. (But I could have easily missed a call, and there may be another method that's doing the appending.) The issue in question isn't so much about determined hackers but hapless users who will bookmark URLs or worse, copy URLs to email to their co-workers. Hapless being the operative word. I think you're stuck with using a filter. - 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
