Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
The Java version wasn't it. Recompiled and redeployed with 1.7.0_25 and it had no effect. The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the JCP on the client side and clicked Restore Security Prompts in the JCP. There was also a problem with JSESSIONID not being sent to the server which was causing the applets call to the server to get a missing sesssion exception. I don't know how that changes when it's the exact same jar file that worked before. We put some code into the applet to force the JSESSIONID to be sent and now it works; as long as TLS 1.1/1.2 are disabled. Sigh. We still haven't identified what caused this in the first place and we're running out of ideas. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
Session cookie is HttpOnly in Tomcat 7.
If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
I added this to some code that is executed by most requests that we use to
track operator activity:
Cookie[] cookies = request.getCookies();
if ( cookies != null ){
for ( Cookie cookie : cookies ){
operLog.append(\n).append(cookie.getName())
.append(=).append(cookie.getValue())
.append(,
secure=).append(cookie.getSecure())
.append(,
httpOnly=).append(cookie.isHttpOnly());
}
}
m_log.fatal(operLog.toString());
This is what that prints out in the log every time:
JSESSIONID=a big hex number, secure=false, httpOnly=false
So no, I don't think that's it. We're set to send on any protocol.
Moreover, shouldn't the applet be sending httpOnly cookies even
if they are not visible to Javascript?
1. Why would it act differently with the load balancer than with a
direct connection?
2. Why would it have continued to fail over the load balancer after
we reverted to Tomcat 6?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote: The HttpOnly flag is used by cookies sent by server to the client. There is no point checking it on request.getCookies(), as browsers do not send it back (neither do they send 'path', 'secure' etc.). Isn't that showing what the server is sending to the client? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote: The HttpOnly flag is used by cookies sent by server to the client. There is no point checking it on request.getCookies(), as browsers do not send it back (neither do they send 'path', 'secure' etc.). 1. Isn't that what gets sent from the server to the client? 2. Why did it work when going direct without the load balancer? 3. Why did it sometimes work with IE even with the load balancer? 4. Why did it still fail when I reverted to Tomcat 6? 5. Why did it work before this release when we had TLS 1.1/1.2 enabled in the client JCP? Note that the load balancer is doing all of the SSL and sending plain HTTP to httpd which is in turn talking AJP to Tomcat. While our httpd does support HTTPS 6. New data point from last night: One of our support people uninstalled Firefox and Chrome and the JRE from his Windows 8 laptop and then reinstalled all of them. All of them worked after that through the load balancer on his laptop. That was before the changes that we made to the applet this morning for the cookie. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Isn't the applet supposed to send browser cookies regardless of if Javascript can see them? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
We tried to upgrade a production server to Tomcat 7 yesterday and it broke our printing applet that we use to control a printer in its native printer language. This seemed odd to us because it worked perfectly in testing. When we go direct to our production servers (bypassing the Cisco load balancer which is doing SSL for us), it also works fine in production. The only thing that's changed is using Tomcat 7. We only have one connector in server.xml Connector port=8009 protocol=AJP/1.3 address=127.0.0.1 redirectPort=443 connectionTimeout=60 maxThreads=1000 maxPostSize=5242880 maxParameterCount=66000 / The Java console is giving an SSLHandshakeException v: dump thread stack x: clear classloader cache 0-5: set trace level to n cache: Initialize resource manager: com.sun.deploy.cache.ResourceProviderImpl@c77c8 basic: Added progress listener: sun.plugin.util.ProgressMonitorAdapter@a2bfd5 basic: Plugin2ClassLoader.addURL parent called for https://myhost.mydomain/myapp/applets/print.jar security: Accessing keys and certificate in Mozilla user profile: null security: JSS is not configured network: Cache entry not found [url: https://myhost.mydomain/myapp/applets/print.jar, version: null] network: Connecting https://myhost.mydomain/myapp/applets/print.jar with proxy=DIRECT network: Cache entry not found [url: file:/C:/Program%20Files%20(x86)/Java/jre7/lib/ext/sunec.jar, version: null] network: Cache entry not found [url: file:/C:/Program%20Files%20(x86)/Java/jre7/lib/ext/sunjce_provider.jar, version: null] network: Connecting http://myhost.mydomain:443/ with proxy=DIRECT javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source) at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source) at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.init(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.io.EOFException: SSL peer shut down incorrectly at sun.security.ssl.InputRecord.read(Unknown
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/4/2014 9:40 AM, Bill Davidson wrote: We tried to upgrade a production server to Tomcat 7 yesterday and it broke our printing applet that we use to control a printer in its native printer language. This seemed odd to us because it worked perfectly in testing. When we go direct to our production servers (bypassing the Cisco load balancer which is doing SSL for us), it also works fine in production. The only thing that's changed is using Tomcat 7. We only have one connector in server.xml Connector port=8009 protocol=AJP/1.3 address=127.0.0.1 redirectPort=443 connectionTimeout=60 maxThreads=1000 maxPostSize=5242880 maxParameterCount=66000 / I realized that I forgot a lot of info: Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25 It worked fine with Tomcat 6.0.37 The applet is bit-for-bit identical. It's built with Java 1.1 compatibility mode. It's some sort of combination of the load balancer and Tomcat 7 not getting along with each other, but there's nothing to indicate that in catalina.out or mod_jk.log or error.log. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/4/2014 11:01 AM, Christopher Schultz wrote: On 3/4/14, 1:26 PM, Bill Davidson wrote: I realized that I forgot a lot of info: Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25 It worked fine with Tomcat 6.0.37 The applet is bit-for-bit identical. It's built with Java 1.1 compatibility mode. It's some sort of combination of the load balancer and Tomcat 7 not getting along with each other, but there's nothing to indicate that in catalina.out or mod_jk.log or error.log. So you have client (applet) - Cisco LB - Tomcat? Or, are there other components in the mix? Does Cisco LB speak AJP13? See above. I have Apache httpd 2.2.25 in there. It's the same httpd I was using with Tomcat 6. What component is handling the SSL handshake on the server side? Apache httpd. Just to clarify, the applet works when connecting /directly/ to Tomcat - -- without the load-balancer in between? How can the client (applet) connect directly to Tomcat if you only have an AJP connector? I don't think it can connect directly to Tomcat. Only have the AJP connector and it's only enabled on the loopback, which the load balancer has no access to. Only httpd can talk to Tomcat; by design. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/4/2014 11:22 AM, Christopher Schultz wrote: Aah, sorry, I had missed that. So, the only change was Tomcat? No upgrade to mod_jk or anything like that? OpenSSL upgrade? Upgraded Java on the client? Everything else *absolutely* the same? Exact same httpd, including mod_jk. Same files. Same directory. httpd was not touched at all. I just tried reverting to Tomcat 6 and the problem is still there, so it keeps getting weirder. If you aren't using SSL at all in Tomcat, then Tomcat isn't likely to be the problem, here. I'm thinking that now too. Can other command-line tools connect -- take the applet out of the picture? Try something like curl, wget, or even OpenSSL's s_client tool. s_client will give you lots of good information about the SSL connection state, too. The applet is the only thing that's having the problem. Everything else works (and this is a massive app). We've also seen the applet work for some people, all of whom were using IE but not others who may be using IE, Firefox or Chrome. We've played with TLS/SSL settings in IE and Firefox. That can change the error message but it still fails. Again, it works fine when connecting directly to Apache httpd and bypassing the load balancer. We've been forced to open up direct access to the ports for that so that our customers can print. We don't like that because we lose the advantages of load balancing and the SSL load is now on our web servers instead of the expensive dedicated hardware that's supposed to be doing that for us. My current suspicion is that the load balancer hardware is going bad. It has two server pools. One is to cover customers in one hemisphere (mostly Australia) and one for the other hemisphere (mostly US/GB/IE). We only updated the servers in the pool for the eastern hemisphere to Tomcat 7. We have the two different pools so that we can have down time during low activity periods. It's just weird that it happened to start having this problem right after we upgraded to Tomcat 7 and only on the pool that got upgraded to Tomcat 7. Rebooting the load balancer involves kicking everyone off of both pools, which means that no matter when we do it, it will be during some non-trivial number of customers prime activity time. We should have gotten completely different load balancers for each pool. Sigh. Mr. CEO, can I please have $25,000-$50,000? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/4/2014 1:24 PM, Christopher Schultz wrote: Well... then you'd need a balancer for each balancer ;) Can you reproduce this issue yourself on your own computer (running the applet locally)? If so, what version of Java is running? That's mostly what I've been doing for the last 24 hours. Java recently made some changes to the SSL code that make it a much bigger pain in the neck to make HTTPS connections for instance. I haven't seen any Remote host closed connection during handshake but presumably that could happen under the right failed-negotiation conditions. Hmm. We were building with Java 1.7.0_25 (I think) when it was working and now we're building with Java 1.7.0_45. Could that actually be it? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
On 3/4/2014 3:13 PM, Mark Eggers wrote: Hmm, is the applet signed, and is the certificate from a trusted authority? Oracle recently made some changes to Java which tightened down applet security. They also made some changes in the security policy that block communication on well-known ports unless you create a policy exception. I got bit by the latter when I moved to 1.7.0_51 on Windows and tried to start up a Derby database. The applet is signed and runs without warning pop-ups. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Notification strategy for OutOfMemoryError
On 1/23/2014 5:21 PM, Christopher Schultz wrote:
If you'd care to post your code to either the list or onto the wiki, I'm
sure it would be useful to someone. Feel free to trim-out huge sections
of the code and say make this fit your environment, etc. if you don't
want to show everyone how bad your email-assembling code looks ;)
Yeah, I don't really want to show my email code. Sending email
will be left as an exercise for the reader.
The filter part of it is barely anything. The method
handleError(Error,ServletRequest) does the work of logging and
sending email. I synchronized that method so that only one can
run at a time in order to minimize memory usage by the filter
if I'm getting multiple Error's thrown.
ErrorNotifier.java
/**
* Catch all {@link Throwable}s and notify on {@link Error}s.
*
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter( ServletRequest request, ServletResponse response,
FilterChain chain ) throws IOException, ServletException
{
try{
chain.doFilter(request, response);
}catch ( Throwable t ){
if ( t instanceof Error ){
try{
handleError((Error)t, request);
}catch ( Throwable tx ){
m_log.fatal(tx.getMessage(), tx);
}
}
throw t;
}
}
private static synchronized void handleError( Error error, ServletRequest
request ) throws UnsupportedEncodingException, MessagingException
{
log and check the error and send email
}
There are also destroy() and init(FilterConfig) methods but they are stubs
that do nothing and are only there because they are required by the Filter
interface.
WEB-INF/web.xml:
!-- Filter to catch java.lang.Error and send emails --
filter
display-nameErrorNotifier/display-name
filter-nameErrorNotifier/filter-name
filter-classcom.mydomain.filters.ErrorNotifier/filter-class
/filter
filter-mapping
filter-nameErrorNotifier/filter-name
url-pattern/*/url-pattern
/filter-mapping
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Notification strategy for OutOfMemoryError
On 12/11/2013 11:42 PM, André Warnier wrote: The original issue of the OP was to be notified ASAP when an OOM occurs. And he indicated that an OOM resulted in a message in the logs. So, something is already catching the OOM exception, to write this line in the logs. On the other hand, there is ample literature available that seems to indicate that any method for trying to recover from (or even do something worthwhile after) an OOM is ultimately flawed and unreliable. We have a lot of servlets and JSP's. Most of them do not use huge amounts of memory but a few do (like reports). When there is a memory leak, the first thing to get an OOME will be something that uses a large amount of memory. That request will die, but the rest of the requests that don't use a lot of memory will have plenty of space for a while. I implemented the filter, and it works in my testing. I also implemented the command line jvm option which works but only gives me the first OOME. The command line option works no matter what and the filter works as long as it doesn't run out of memory generating the email message. We'll see how it all works after it gets deployed to our production systems in a few weeks. Our product is mature enough that we've fixed memory leaks to the point that we normally go many months without any OOME's so it could be a while before this actually kicks in for a real operating situation. Thanks to Christopher for the ideas. They were very helpful. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Notification strategy for OutOfMemoryError
On 12/11/2013 7:14 AM, Christopher Schultz wrote: 3. cath IOException in a filter and set an application attribute. Check this attribute from your monitor. I've been considering doing this, because I can rig it so that the error handler does not actually require any memory to run. The problem is that sometimes OOMEs interrupt one thread and not another. You may not catch the OOME in that thread -- it may happen in a background thread that does not go through the filter. I'm not sure I understand this one. How does an IOException relate to an OOME? Sorry, I meant of course OutOfMemoryError. Just make sure you use as little memory as possible during the exception handler or it will fail itself and possibly mask the original problem. - You can catch an OOME in a fiter? I would not have expected that. Off to the documentation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Notification strategy for OutOfMemoryError
On 12/9/2013 5:20 PM, Bill Davidson wrote: On 12/9/2013 3:12 PM, Christopher Schultz wrote: 1. Use -XX:OnOutOfMemoryError=cmd args;cmd args Rig this to email you, register a passive-check data point with your monitoring server, etc. Just remember that OOMEs happen for a number of reasons. You could have run out of file handles or you could have run out of heap space. That looks interesting. It wouldn't tell me about the error but at least I'd know that there was an OOME. Better than nothing and I can go check catalina.out. Of course, I still have the problem that threads silently fail and show my users not so much as an error message. I have implemented this one. The only real down side is that it only fires for the first one. Admittedly, I don't want to see hundreds of these but getting pinged every few minutes would probably be good. I may rig up a way for my script to do that until I turn it off. Still not entirely sure how to do the other ones. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Notification strategy for OutOfMemoryError
Last week, one of my servers got an OutOfMemoryError at approximately 1:21pm. My monitoring software which does a heart beat check once per minute did not notice until 3:01pm. Heart beat kept working for over an hour and a half. During that time my high capacity high availablity 24/7 application was getting occasional OutOfMemoryError's until memory got bad enough that even the heart beat check servlet failed. Apparently some things that allocate large chunks of memory started failing first, but none of my customers called to complain. Smaller stuff continiued to work. I didn't know until my monitoring software sent me an email about the heart beat failure. That doesn't work for me. I need to know sooner. I thought of trying to handle it with error-page in web.xml. Apparently that does not work. I used java.lang.Throwable as the exception-type. I was already using this for a number of common exceptions to send me email. I see the OutOfMemoryError's logged in my catalina.out Is there some way that I can catch this so that I can send email or something? I need to know as soon as possible so that I can attempt diagnosis and restart the server. Google has not been helpful. Everything says that you have to fix the memory leak. Duh. I know that. We've fixed many over the years. We haven't had one in nearly 2 years. We thought we'd fixed them all. We need to find out about them sooner when they do happen. This was on Tomcat 6.0.37 in production but we are about to upgrade to 7.0.47 and have been using that in development for a little over a month. My testing has been in development (7.0.47) and I tested by explicitly throwing OutOfMemoryError from a servlet. Logged in catalina.out but no other indication that it happened. My error page does not get called. error-page exception-typejava.lang.Throwable/exception-type location/jsp/error/Error.jsp/location /error-page RedHat EL 5.9. Java 7.0.25 64-bit. Heap size 3GB. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Notification strategy for OutOfMemoryError
On 12/9/2013 3:12 PM, Christopher Schultz wrote: Was it a transient error, or a chronic condition? A single thread can, for instance, spew objects into its stack or eden space exhausting memory but, when that thread hits the OOME, all those objects are freed which basically recovers from the situation. If, instead, you fill-up some shared cache, buffer, etc. and NO threads can get more memory, then you're basically toast. Which of the above was it? It looked more like the first one though we still haven't tracked down the cause. We had several dozen threads running at the time. That's common for us. It's not that unusual for us to have a couple of hundred users with active sessions per server at any given time. There are a bunch of things you can try to do. They all have their caveats, failure scenarios, and inefficacies. 1. Use -XX:OnOutOfMemoryError=cmd args;cmd args Rig this to email you, register a passive-check data point with your monitoring server, etc. Just remember that OOMEs happen for a number of reasons. You could have run out of file handles or you could have run out of heap space. That looks interesting. It wouldn't tell me about the error but at least I'd know that there was an OOME. Better than nothing and I can go check catalina.out. Of course, I still have the problem that threads silently fail and show my users not so much as an error message. 2. Use JMX monitoring, set java.lang:MemoryPool/[heap space]/UsageThreshold to whatever byte value you want to set as your limit. Then, check java.lang:MemoryPool/[heap space]/UsageThresholdExceeded to see if it is true. If so, your usage threshold has been exceeded. Note that this is not proof-positive than an OOME occurred. It's also tough to tell what value to use for the threshold. You can't really set it to MaxHeap - 1 byte, because you'll never get that value in practice. If you set it too low, you'll get warnings all the time when your heap usage rises in the normal course of business. I'm less enthused about that one. 3. catch IOException in a filter and set an application attribute. Check this attribute from your monitor. I've been considering doing this, because I can rig it so that the error handler does not actually require any memory to run. The problem is that sometimes OOMEs interrupt one thread and not another. You may not catch the OOME in that thread -- it may happen in a background thread that does not go through the filter. I'm not sure I understand this one. How does an IOException relate to an OOME? 4. You can do what I do: simply look at your total heap space by inspecting java.lang:Memory/HeapMemoryUsage[used] and set a threshold that will cause your monitor to alarm for WARNING and CRITICAL conditions. You may recover and not have to check anything. These days, I get a false-alarm about once every 3 weeks when the heap space grows a hair higher than usual before a full GC runs and clears everything out. The nice thing about #4 is that you can find our early if you *might* be having a problem. Then you can keep an eye on your service to make sure it recovers. If it never OOME's, great. If it does, you can manually restart or whatever. If it OOME's, and #1-#3 above fail because memory might be required to actually execute the do-this-thing-on-OOME action, then you might never get notified. With #4, you don't have to wait until an OOME to take action. Is there a way I can get to this from my heartbeat servlet? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
-d64 disappears from command line in ps output?
RedHat 5.6 64-bit java -version output: java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Tomcat: 6.0.26 The -d64 option seems to be removed from the ps command line arguments: I added a set -x to $CATALINA_HOME/bin/catalina.sh so that I could see the actual java invocation: + /path/to/jdk1.6.0_20/bin/java -Djava.util.logging.config.file=/path/to/logging.properties -d64 -Xms3072m -Xmx3072m (...various app specific -D options...) -Djava.awt.headless=true -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/path/to/apache-tomcat-6.0.26/endorsed -classpath /path/to/apache-tomcat-6.0.26/bin/bootstrap.jar -Dcatalina.base=/path/to/tomcat -Dcatalina.home=/path/to/apache-tomcat-6.0.26 -Djava.io.tmpdir=/path/to/tomcat/temp org.apache.catalina.startup.Bootstrap start When I do a ps aux I see this: /path/to/jdk1.6.0_20/bin/java -Djava.util.logging.config.file=/path/to/logging.properties -Xms3072m -Xmx3072m (...various app specific -D options...) -Djava.awt.headless=true -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/path/to/apache-tomcat-6.0.26/endorsed -classpath /path/to/apache-tomcat-6.0.26/bin/bootstrap.jar -Dcatalina.base=/path/to/tomcat -Dcatalina.home=/path/to/apache-tomcat-6.0.26 -Djava.io.tmpdir=/path/to/tomcat/temp org.apache.catalina.startup.Bootstrap start Where did the -d64 option go? I'm pretty sure that this is OK and that the JVM just modified its argument line while using the 64 bit memory model but it still makes me slightly nervous. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: -d64 disappears from command line in ps output?
On 8/10/2011 2:57 PM, Caldarale, Charles R wrote: 1) In what way does this concern Tomcat? I wasn't sure if it had something to do with the way it was launched. 2) Documentation for -d64 with a standard launcher seems to indicate it's only applicable for Solaris (although some other tools look at the setting before launching the JVM). I don't see that: http://download.oracle.com/javase/6/docs/technotes/tools/solaris/java.html *-d32* *-d64* Request that the program to be run in a 32-bit or 64-bit environment, respectively. If the requested environment is not installed or is not supported, an error is reported. Currently only the Java HotSpot Server VM supports 64-bit operation, and the -server option is implicit with the use of -d64. And the -client option is ignored with the use of -d64. This is subject to change in a future release. If neither*-d32*nor*-d64*is specified, the default is to run in a 32-bit environment, except for 64-bit only systems. This is subject to change in a future release I just now found this in the HotSpot FAQ: http://www.oracle.com/technetwork/java/hotspotfaq-138619.html For consistency, the Java implementations on Linux accept the -d64 option. Are you saying that the Linux64-bit Java is 64 bit only and therefore this option is irrelevant? If that is true, then the Java man page is deficient and confusing. 3) What do you think -d64 does? It runs the program in a 64-bit environment. I've got my heap set to 3GB. I was running out of memory with 2GB. I may have to up it further in the not too distant future.
Filters and JSP
Tomcat 6.0.29
I've written a response filter for my web app and it seems to work fine
for servlets but not for JSP's. I
public void doFilter( ServletRequest request, ServletResponse
response, FilterChain chain ) throws IOException, ServletException {
chain.doFilter(request, new
MyResponseWrapper((HttpServletResponse)response));
}
private class MyResponseWrapper extends HttpServletResponseWrapper {
private MyOutputStream myOutputStream;
private PrintWriter printWriter;
public MyResponseWrapper( HttpServletResponse response ) throws
IOException {
super(response);
myOutputStream = new MyOutputStream(response);
OutputStreamWriter osw = new
OutputStreamWriter(myOutputStream, response.getCharacterEncoding());
printWriter = new PrintWriter(osw);
}
public ServletOutputStream getOutputStream() throws IOException {
return myOutputStream;
}
public PrintWriter getWriter() throws IOException {
return printWriter;
}
}
MyOutputStream extends ServletOutputStream and wraps the methods in
the stream returned by response.getOutputStream(). The write() routines
do some manipulation of the output and send the modified output to the
wrapped stream.
The problem seems to be that it only calls write(byte[], int, int) once when
it's a JSP. It will get called multiple times for a servlet but just
once for
the JSP. It's getting called with offset = 0 and len = 8192, and
that's about
how much output I get. My page is always truncated. Obviously there is
some sort of buffered writer calling my write() routine. All of the output
methods from ServletOutputStream are overridden and logged, so I know
what is getting called.
Also, flush() gets called at the end for servlets but never gets called
for a JSP.
I don't get any exception messages in my log.
Is it something wrong in my config?
filter
display-nameMyFilter/display-name
filter-nameMyFilter/filter-name
filter-classcom.mycompany.filters.MyFilter/filter-class
/filter
filter-mapping
filter-nameMyFilter/filter-name
url-pattern/servlets/*/url-pattern
url-pattern/jsp/*/url-pattern
/filter-mapping
Is there something I need to do in my JSP's?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Missing something with custom tags.
version 1.6.0_20, Java(TM) SE Runtime Environment (build
1.6.0_20-b02), Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed
mode)
Tomcat: 6.0.26
I'm having trouble with a custom tag and I've tried to reduce the
problem to its most basic form:
/WEB-INF/tags/example.tag:
%@tag %
%@attribute name=xName required=true rtexprvalue=true %
h1xName=${xName}/h1
/jsp/Example.jsp:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
%@page language=java contentType=text/html; charset=UTF-8
pageEncoding=UTF-8 %
%@taglib prefix=ex tagdir=/WEB-INF/tags %
html
body
ex:example xName=Testing Example /
/body
/html
I usually get:
You have run into a org.apache.jasper.JasperException:
/jsp/Example.jsp(6,4) Unable to find setter method for attribute: xName
error.
But sometimes I get this:
You have run into a java.lang.ClassNotFoundException:
org.apache.jsp.jsp.Example_jsp error.
Any idea what I'm doing wrong? From what I can see, my code seems to mirror
examples I've found in books and on the web. Intermittent results
suggest a race
condition to me though that seems odd here. I've not had good luck with
google on
this error.
Full stack traces for the exceptions here:
Feb 2, 2011 1:55:02 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: /jsp/Example.jsp(6,4) Unable to find
setter method for attribute: xName
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
at
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
at
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:148)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:2809)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3032)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomDoTag(Generator.java:2452)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1736)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
at
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:495)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
at
org.apache.jasper.compiler.Generator.generate(Generator.java:3440)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:231)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
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
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
Feb 2, 2011 1:55:29 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.ClassNotFoundException:
Re: Missing something with custom tags.
On 2/2/2011 2:17 PM, Konstantin Kolinko wrote: I think you are bumping into JavaBeans capitalization rules. Rename your attribute to be xname or xxName. That worked. Weird. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Missing something with custom tags.
On 2/2/2011 2:17 PM, Konstantin Kolinko wrote: I think you are bumping into JavaBeans capitalization rules. Rename your attribute to be xname or xxName. That worked! Thanks! I think that's a pretty weird thing. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: iCal4j and ThreadLocal
On 8/30/2010 9:18 PM, Caldarale, Charles R wrote: There's a lot of baggage implemented to support ThreadLocal. It's one of those deceptively easy-to-use Java concepts that utilizes a lot of plumbing underneath the covers (e.g., a specialized per-thread expandable hash map, weak references). The basic implementation is that of a hash map per thread, using the ThreadLocal object as the key, and the reference from the argument to ThreadLocal.set() as the value. There's no actual requirement that the values are in fact thread-local, but they usually are so that synchronization can be avoided. There needs to be a balance between caching/pooling and abuse of memory. Caching/pooling needs to be worth the trouble of doing it and the memory it takes up. For example in iCal4j with SimpleDateFormat, I don't really see why it's so important to have it static. It seems to me that using static ThreadLocal's isn't going to save that much overhead vs. just creating a regular local object each time you run. It seems to me that things like that should be reserved for something that's more expensive to create, like something that requires doing I/O. A SimpleDateFormat doesn't require any I/O to be created. Its format string might come from a ResourceBundle but I believe those only do I/O the first time they are loaded. I do some static caching in my app but it's of data pulled from a database on another host, making it expensive to create. It's also data that gets used frequently but changes rarely. Synchronization around a HashMap or Hashtable is cheaper than hitting the database. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: iCal4j and ThreadLocal
On 8/31/2010 12:16 PM, Christopher Schultz wrote: Or, just remove the ThreadLocal manually. Since you know it's name, it should be easy to remove. There are two obvious ways to remove these ThreadLocals in a webapp: 1. Modify all the code that uses the iCal4j library so that, after performing it's iCal4j operations, you manually remove the ThreadLocals. I don't understand how to do that. I have local objects that I create from the library. Once I'm done with them, they go out of scope and are given to the garbage collector. However, the ThreadLocal's are static to the class, and the library offers no way to access them. Is there some way to find them? Hmm, now that I think about it, Tomcat found them. I guess I should look at the Tomcat source. 2. Write a Filter that removes any ThreadLocals once the request has been completed. Again, I'm not sure how to do that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
iCal4j and ThreadLocal
Sigh. Using Tomcat 6.0.26 and trying to use iCal4j to generate calendar
files so that date/time events in my app can be exported to the user's
calendar.
iCal4j uses static ThreadLocal's to protect SimpleDateFormat and some
other things. When I shut down Tomcat I get these disturbing messages:
Aug 27, 2010 4:40:02 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[net.fortuna.ical4j.model.DateTime$1] (value
[net.fortuna.ical4j.model.datetim...@19ed13da]) and a value of type
[java.text.SimpleDateFormat] (value
[java.text.simpledatefor...@6f64295a]) but failed to remove it when the
web application was stopped. To prevent a memory leak, the ThreadLocal
has been forcibly removed.
Aug 27, 2010 4:40:02 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[net.fortuna.ical4j.util.CompatibilityHints$1] (value
[net.fortuna.ical4j.util.compatibilityhint...@1bb25a82]) and a value of
type [java.util.HashMap] (value [{}]) but failed to remove it when the
web application was stopped. To prevent a memory leak, the ThreadLocal
has been forcibly removed.
Aug 27, 2010 4:40:02 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[net.fortuna.ical4j.model.DateTime$3] (value
[net.fortuna.ical4j.model.datetim...@5a541b02]) and a value of type
[java.text.SimpleDateFormat] (value
[java.text.simpledatefor...@d70c6dda]) but failed to remove it when the
web application was stopped. To prevent a memory leak, the ThreadLocal
has been forcibly removed.
The iCal4j author assures me that this isn't really a memory leak.
It's just creating some small static variables on per thread basis.
Of course, I run up to a couple hundred threads per server so I'm not
so sure. I know I don't like seeing these messages in my log. They are
particularly annoying for development because I look at my logs a lot
and I don't like the extra useless noise.
I'm not really clear on how ThreadLocal works. Is there no way for me
to kill these?
Alternatively, if it really is harmless, is there a way to turn off
these messages?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: iCal4j and ThreadLocal
On 8/30/2010 2:08 PM, Caldarale, Charles R wrote: I'm not really clear on how ThreadLocal works. http://download.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html And, as usual, GIYF. I actually had already read that, and a few other things I found in Google. It still felt a bit fuzzy to me. It's getting a little more in focus but it's kind of a weird thing. Thanks for the response. I've forwarded that information and Mark's to the author. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat DBCP
On 6/9/2010 2:15 AM, Altanis Alexandros wrote: I have been reading about the new Tomcat DBCP in a couple of blogs lately, as I am interested in Connection Pooling for an application I am working on. Here they are: http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html http://www.tomcatexpert.com/blog/2010/04/01/configuring-jdbc-pool-high-concurrency http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html (I'm a little behind on the list, and trying to catch up) Interesting. I was not aware of this other connection pool for Tomcat. I'd be very interested in finding something faster than DBCP, which I have found disappointing (I've got a lot of concurrency going on my servers). Based upon those links, it appears that you have to get the SpringSource tc server to get the pool? Is this is a SpringSource commercial (not free) product? That would explain why I don't see any mention of it in the regular Tomcat docs. As near as I can figure, it isn't part of the Apache Foundation site. That last link makes it look like it's part of Tomcat 7, but from what I can tell, it is not. If it is available free, then what is the appropriate method of getting it? If we don't want to buy SpringSource tc, do we need to check it out from SVN and build it? I can't find a normal home page for it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Elli Albek wrote: 2. If your JDBC driver supports caching of prepared statements and metadata, do it in the driver and disable this in DBCP. IMO DBCP does a poor job at best in caching. We use mysql and its JDBC driver is doing an excellent job. It didn't occur to me that that was available. 3. Your JDBC driver may already be caching metadata that DBCP is caching. In this case you are caching the same data twice. Make sure it dose not happen, it is a big memory overload on the JVM. Interesting. I need to do more research. B. Avoid hot deployment of apps by shutting down tomcat before updates. This is safer, but also not 100% clean. We're actually doing that already, but for other reasons. We currently have different servers for different parts of the world and schedule down time for off-peak periods for the regions they serve. Thanks for the info. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote: When you've played with it for a bit, tell us how things turned out. It's looking like optimal is caching about 40 PreparedStatement objects. However, I should qualify that noting that it's with our application and specifically with our little pummeling benchmark, which requests a specific subset of services, and probably isn't even a great test of real world traffic. It was mainly designed to see how the app handled being heavily stressed (like getting hit with 1000 requests at a time). The system is still about 3-4% slower with DBCP than with our old pooling library. Our old pooling library did not wrap the Connection objects like DBCP does, though it did close old Connection objects so that they only got reused for up to two minutes at a time. I'm actually a little surprised by this. I would have expected that to make DBCP faster, since it keeps them open. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
I already got a response to the ehancement request. Apparently the documentation will be changed to this: Make sure your connection has some resources left for the other statements. Pooling PreparedStatements may keep their cursors open in the database, causing a connection to run out of cursors, especially if maxOpenPreparedStatements is left at the default (unlimited) and an application opens a large number of different PreparedStatements per connection. To avoid this problem, maxOpenPreparedStatements should be set to a value less than the maximum number of cursors that can be open on a Connection. Looks good to me. Not sure if it will have to wait for 1.3 or if they will work it into the current documentation after some review. Bill Davidson wrote: Christopher Schultz wrote: I see you've cross-posted to commons-user. That's good, but you probably want to file an actually bug report / enhancement request for the documentation. Filed. Key: DBCP-301 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote: I see you've cross-posted to commons-user. That's good, but you probably want to file an actually bug report / enhancement request for the documentation. Filed. Key: DBCP-301 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote: I'm curious about the usefulness of caching prepared statements in general, though. What is the default maxOpenPreparedStatements setting and what did you set it to in order to get it to work out well for you? The default is unlimited, which is the problem. I've been playing with different settings to try and find the best one, but obviously, it needs to be less than 300. If you have 100 different prepared statements in your code and you are only allowing a connection to cache, say, 5 of them, then I have to expect that you'll be constantly thrashing your cache as new statements are prepared and executed. Do you see a performance gain between disabling statement caching and enabling it, but setting the cache size relatively low? That's one of the things I'm hoping to find out. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote: Uh, oh. Are you doing something like this: Possibly. I didn't write that code. If you're doing that, then you're probably making a big mistake. Are you storing connections in sessions or anything like that? Yuk. For certain transactional operations, I think it is. 1. Thread 1 returns a connection with an uncommitted transaction to the pool. Mistake: see above. I know it's a mistake. I'm not sure that that is what is happening. It's just a hypothesis. I'm still interested in what happens if you disable prepared statement pooling. I finally figured out how to make the app use up the cursors consistently so I tried disabling PreparedStatement pooling a few minutes ago. That makes the problem go away. I can make cursors accumulate with it turned on. I can't with it turned off. That makes me think it's not the app after all. However, it also makes me concerned about performance. Interactive performance on my test machine is nice and fast. However, the performance problems show up when the system is being pummeled by hundreds or thousands of visitors to the site simultaneously (I have a script that can simulate such pummeling against the server). Would this then be considered a problem with DBCP's PreparedStatement pooling? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Just thinking about this some more So apparently, when I was using poolPreparedStatements=true, and I did conn.prepareStatement(SomeSQLString), I was getting back a Statement object created by DBCP to be pooled. When I called close() on that statement, it did not really close(), which was leaving lots of open cursors around. Could maxOpenPreparedStatements possibly fix this? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Bill Davidson wrote: Could maxOpenPreparedStatements possibly fix this? Apparently it does. The DBCP config docs need a better warning on poolPreparedStatements: *NOTE* - Make sure your connection has some resources left for the other statements. just doesn't quite cut it. Something more like: Pooling PreparedStatement's may keep their cursors open in the database, causing you to run out of cursors. You should also set maxOpenPreparedStatements to some value less than the maximum number of cursors you can have on a Connection. or something along those lines. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote: Is it possible that your server just doesn't want to allocate 245 * 4 cursors, and that you are just hitting that barrier? cursor != connection Oracle is set up to allow up to 300 cursors per session (connection). I could up that limit, but it probably won't fix the problem, as these things seem to just keep accumulating. I though you said that after a connection was checked-out for 120 seconds, it was forcibly closed by the connection pool. Only when it is sent back to the pool by the servlet. The pool manager doesn't have a background thread looking for old connections to kill. It's not a work around for connection leaks. Apparently it's a work around for cursor leaks. Oh, so this query is intended to find out what is happening on the server side, so you can see what cursors are open and what their queries are. I thought you meant that a query such as this was being executed from your webapp. Correct. Sorry if I didn't make that clear. Those queries are not in my webapp. They are only used to help track down lingering cursors. For people not familiar with Oracle, special characters like '$' in FROM clauses are usually an indication of something being in Oracle's data dictionary which keeps track of everything in Oracle. The other one in that query was v$session which keeps track of session information. A session, in this context, is a connection. Do some of those methods have multiple queries being executed? If so, it's possible that one statement remains open while the second one is closed. For example: A very small number do, but the vast overwhelming majority do not. I'm finding these lingering cursors on all sorts of things. On the ones that do, they are all still closed. This is perfect. I noticed that I don't see a conn.close in there (which is probably appropriate, given that the Connection object is a parameter to the method). I assume you have similar finally blocks in calling methods, right? Correct. I'm not seeing anything resembling a connection leak problem. This is strictly a cursor problem. The eviction run will only to remove connections from the pool: it won't fix any resource allocation problems. Your webapp and server ought to be able to tolerate all connections being open and active at once (so, a full 245 connections in each webapp instance, and 980 connections on the server). The Oracle instance is set up to handle 1000 connections. Tomcat has maxThreads=240, just because I'm paranoid and want to leave a little slop factor. I shouldn't ever see more than 240 actual connections per server. The only thing the eviction will really help with is reducing the memory being used on both the client and server. I suppose that calling a true close() on the connection might clean-up any sloppiness going on in the client OR the server, and thus might solve your problem, but I believe it will be merely hiding the symptom, not actually solving the underlying problem. I suspect that you are correct. I'm baffled as to why I have old cursors lying around. The close call on the statements has to happen. Do you have access to an Oracle DBA? They may be able to help uncover the implications of some of the queries being run... it's possible that cursors are being allocated that you didn't expect, or that aren't being closed for /other/ reasons. The Oracle DBA that I have access to doesn't know much about Java/JDBC which is why I was hoping I could find some Oracle expertise in the commons or tomcat lists. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Martin Gainty wrote: are you running as a Transaction? In some cases, but a lot of these lingering cursors are on very simple queries, with no insert/update/delete involved. As I said before, I'm finding lingering cursors on things as simple as SELECT * FROM some_table WHERE id = ?. That does make me wonder though if there are Connection's getting sent back to the pool that had a pending transaction without a commit/rollback and if that could be making any cursors on that connection after that linger? It might explain the randomness of the queries showing up in the list. It also gives me a question I can send to my Java-challenged Oracle DBA. Thanks for the idea. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote: Probably not. DBCP calls setAutoCommit(true) by default in order to reset the connection as it goes back into the pool. Any pending transaction is committed (!) when that happens, so there shouldn't be any in-progress transactions lingering around. If you set autoCommit=false in your DBCP configuration, that might change things. Are your transaction finally blocks and commit/rollback logic blocks sane? You can refer to my previously-mentioned blog post for my thoughts on how to do it properly. I'm a little confused about auto-commit. I don't want my transactions auto-committed. Sometimes there's a need for a rollback of an entire transaction. To my thinking, auto-commit implies that you don't have true transactions. The transactions in the app are a lot more complex, and a transaction can hold onto a connection for quite a while as a user is editing things. The queries themselves have the same try-catch-finally situation but there can be quite a few different calls on that connection for one transaction. But what is the likelihood of SELECT * FROM foo WHERE foo.id=? appearing in a transaction? Very low. The scenario I was describing was: 1. Thread 1 returns a connection with an uncommitted transaction to the pool. 2. Thread 2 gets the same connection from the pool and does a query on it 3. The query from Thread 2, unrelated Thread 1, ends up in cursor limbo because of the uncommitted transaction on the connection. I don't know that this is happening in the app, and it's going to be very difficult to find it if it is. I don't even know that this scenario could cause this cursor limbo. It's just a hypothesis which is hard to test. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
DBCP woes (running out of cursors).
Redhat 5.2 Server Java: Sun JDK 1.6.0_16 (64-bit) Tomcat 6.0.20 (and whichever version of DBCP that includes) Oracle 10g (10.2.0.3) JDBC: ojdbc14.jar I've been trying to convert an old J2EE application to use DBCP connection pools from an old custom connection pool class (not a DataSource interface). The old pool worked acceptably, and DBCP seemed to work fine in development, but then I got it into a test environment and had a bunch of people beating on it and I started running out of cursors. Looking through the old code, it turns out that the old pool manager, when freeing a Connection, had kept track of when it created that Connection and if it was more than 120 seconds old, it closed it and made a new one. As a result, a given Connection wouldn't hit the cursor limit because it wouldn't get reused for more than 2 minutes. So, I think: We must have code that's not closing ResultSet/Statement objects so I go off looking for them. With a little research, I come up with queries like this: SELECT a.sid, b.status, b.osuser, b.machine, to_char(b.logon_time, 'dd-mon- hh24:mi:ss') logon_time, a.user_name, a.sql_id, a.sql_text FROM v$session b, v$open_cursor a WHERE a.sid = b.sid AND a.user_name = 'APPUSERNAME' ORDER BY upper(a.sql_text), b.status; SELECT count(a.sql_text) count, a.sql_text FROM v$session b, v$open_cursor a WHERE a.sid = b.sid AND a.user_name = 'APPUSERNAME' AND b.status = 'INACTIVE' GROUP BY a.sql_text ORDER BY count desc, upper(a.sql_text); I run these against production (which is still using the old pools) and I find all sorts of queries lying around on inactive sessions, which I'm guessing are Connections that were closed. I then start tracking the SQL down and every single one has an iron clad close() call in a finally clause. There is absolutely no way the close() is not being called on the Statement objects. Many of them even explicitly close() the ResultSet objects even though that should be handled by closing the Statement objects. These close() calls are happening immediately after the data is gathered from the ResultSet's. I then went looking in active sessions in the test environment and it's the same thing. I can't find any lingering cursors for SQL that doesn't have a Statement.close() call that's guaranteed to run. I've got lots of open cursors. I can't explain why. The config I'm using for DBCP (other than connection info): maxActive=245 maxIdle=16 validationQuery=SELECT 1 FROM dual poolPreparedStatements=true accessToUnderlyingConnectionAllowed=true Since I've eliminated the possibility that close() is not being called on Statement/ResultSet's, I'm wondering a number of things: 1.Could this be a bug in the Oracle JDBC driver? 2. Should I change parameters for DBCP? - Should I get rid of poolPreparedStatements? Note: That noticeably hurts performance. - Should I use timeBetweenEvictionRunsMillis - What's an eviction run? - Should I reduce maxIdle? 3. Is there a newer version of DBCP than the one that comes with Tomcat that might mitigate this problem and is it a good idea to drop that into Tomcat? Any useful advice would be appreciated. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP woes (running out of cursors).
Christopher Schultz wrote:
On 10/14/2009 2:17 PM, Bill Davidson wrote:
Redhat 5.2 Server
Wow.
Maybe I should have said RHEL 5.2. 5.3 would be the current
version, so it's actually not that old. RedHat's starting over with
the numbers does get confusing.
This config looks fine, though the maxIdle might be a little low. IIRC,
setting-up Oracle connections is a time-consuming operation. If you
really need 245 connections, perhaps you might want to increase the idle
count to improve the performance of your webapp when demand suddenly
hits a mostly-idle server.
Usually, we don't need that many, but sometimes, we get hit really hard
with a lot of traffic and do need that many. BTW, this is load balanced
across 4 servers that can each do 245 connections.
Similar capability is found in DBCP in the form of the removeAbandoned
and logAbandoned configuration parameters. See the configuration for
DBCP on this page:
http://commons.apache.org/dbcp/configuration.html
/Important note:/ the removeAbandoned configuration parameter will
merely remove the discarded connection from the pool. It will /not/
close the connection after that timeout, so it won't solve your problem:
it will only help you find the problems in your webapp.
I thought that was for Connection leaks. If we had Connection leaks,
then the old pools wouldn't work properly either, because the old pools
only kill connections when the servlets free the Connection (the same
as close() on a DBCP connection). The Connection's are being sent
back to the pool, but apparently with open cursors lingering.
I don't know a thing about Oracle-specific queries, but what does:
v$open_cursor a
mean? Does this explicitly open a new cursor, or use an existing one
called a?
v$cursor is a view in the Oracle data dictionary that shows currently
open cursors in the current Oracle instance. The sql_text column shows
the first 40-50 characters or so of SQL being executed for that cursor.
It shows them for both active and inactive sessions. I'm only guessing
that the inactive sessions are from Connection's that are closed without
having all of their ResultSet's closed. That might be incorrect.
Finding concrete information is difficult.
Technically speaking, the JDBC specification requires that calling
Connection.close() also close any Statement (and therefore ResultSet)
objects that were opened as well. The lines become blurred a bit when
you're talking about pooled connections, because Connection.close()
doesn't really get called... it's a grey area in the spec if you ask me,
but I'd prefer that a pooled connection act like a non-pooled connection
in this case, but there's no recycle or reset method in the
java.sql.Connection class, and calling Connection.close() on the actual
connection is not appropriate (since it's pooled) so there may be no way
to actually implement this mimicry.
Maybe, but as I said, I've tracked down the SQL for all of the open
cursors that don't seem to go away and they all have guaranteed close
calls on the Statement's, and many also have them on the ResultSet's.
A lot of the SQL is not that funky either. A lot of it is as simple
as grabbing a single record SELECT * FROM some_table WHERE id = ?
or a few records like SELECT * FROM some_table WHERE some_col = ?.
Can you post an example of your finally blocks? If each xyz.close()
isn't in a try/catch block of its own, it could potentially fail to
return the Connection to the pool. In this case, logAbandoned will help
you a lot. I recommend enabling that setting even in production,
especially because that's where it's easiest to exercise your webapp's
DB access code.
Basic pattern:
public Vector someFinder( Connection conn, long param )
{
PreparedStatement statement = null;
ResultSet rs = null;
Vector result = new Vector();
try{
statement = conn.prepareStatement(SomeSQLString);
statement.setLong(1, param);
rs = statement.executeQuery();
while ( rs.next() ){
// findResult does the ORM in our app.
result.add(findResult(rs));
}
}catch ( Exception e ){
// logging, plus possible wrap-and-re-throw
}finally{
// sometimes the ResultSet is explicitly closed,
// other times not. It shouldn't matter.
if ( rs != null ){
try{
rs.close();
}catch ( SQLException ex ){
// log it.
}
}
// Statement's are always explicitly closed.
if ( statement != null ){
try{
statement.close();
}catch ( SQLException ex ){
// log it.
}
}
}
return result;
}
- Should I use timeBetweenEvictionRunsMillis - What's an eviction run?
It's what happens every so often to flush-out all the connections that
have been
Re: Using multiple DataSource's for fail-over.
Mohit Anchlia wrote: Something like this: (DESCRIPTION=(FAILOVER=ON)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=x)(PORT=1526))(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1526)))(CONNECT_DATA=(SERVICE_NAME=somesid))) I still haven't been able to locate the documentation, but that seems to make connections. I'm wondering if I need to configure the DBCP connectionProperties attribute with anything special for fail-over? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using multiple DataSource's for fail-over.
Ognjen Blagojevic wrote:
IANA-failover-expert, but one question comes to my mind. What happens
when the first server is recovered? Some cached connections will still
point to second server, while newly created connections will go to the
first one?
Actually, it doesn't switch which is the primary. It keeps trying
the primary every time and failing over to the secondary every
time the primary fails. When the primary comes back, it will
get the primary.
Basic logic is this:
try{
conn = primary.getConnection();
}catch ( SQLException e ){
conn = secondary.getConnection();
}
return conn;
I'm a little concerned that the first failure might take time
due to having to wait on a timeout or something like that.
That could kill performance, so that's one of the reasons
I'm asking about it here.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using multiple DataSource's for fail-over.
Tim Funk wrote: I thought the Oracle JDBC driver allowed for all the nodes to be placed into the connect string and the driver was smart enough to detect failover. [So its a configuration exercise on the connection string.] I'm having trouble finding documentation for this capability. Can you or someone else provide a pointer? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using multiple DataSource's for fail-over.
Tomcat 6.0.20 using DBCP DataSource Java 1.6.0_16 Oracle 10g with RAC. I've got two Oracle RAC nodes, mirroring each other. My current fail-over method if the primary node fails is to shut down the web servers, reconfigure them to use the secondary node and restart the web servers. Not pleasant. I'm thinking I can make a FailOverDataSource that implements DataSource and wraps around DataSource's for each of the two nodes. Its getConnection() method would try to use the getConnection() from the primary node, and if that fails, it would try the secondary node. Repeat logic for other DataSource methods. Instant automagic fail-over. I've actually written it, and it seems to get a hold of both DataSource's fine. I can't kill the primary on an active busy system to do a real test though. I'm thinking I can't be the first person to think of this. Are there any obvious problems with this idea? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
DBCP config question
Tomcat 6.0.18 Oracle 10g Java 1.6.0_14 I'm a little curious about the defaultAutoCommit parameter. If I understand the docs and things I've googled correctly, if I don't set it, I get the JDBC driver default. More googling, suggests that the default for the Oracle JDBC driver is to have auto-commit enabled. I'm pretty sure I don't want that since I have some complex transactions going on. So I'm thinking I should set it to false to disable auto-commit. Is that correct? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Converting to container based security.
Mark Thomas wrote: Alternatively, you could use a database view to present the two sets of users as a single table. What about duplicated user names between the two sides? There's also the need to make sure that the admin side servlets are not accessible to the public side and vice versa and that the public side servlets are accessible without authentication but the admin side servlets are not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Converting to container based security.
Tomcat 6.0.18 Java 1.6.0_14 RedHat 5.2 Server Oracle 10g I've got an old web app that was originally spec'd in 1999. Last year, I got it migrated from Tomcat 3.2.4 for 6.0.16 and more recently from Java 1.4.2 to 1.6. I'm gradually trying to modernize it. I just converted from using an old database connection pool library from that period to using a DataSource managed by Tomcat/DBCP (which was surprisingly easy). Now I want to tackle container based security. The app currently manages its own security. It's all servlets which do a little session magic on their own. The login servlet hits the database where the user names and password are. I want to start using JSP and/or maybe JSF, which is part of the reason I want to go to container based security. I'm thinking that the login.jsp can be set up with a bean to massage the session so that old servlets will still be satisfied that the session is legit. Newer servlets can dispense with that security and older ones can have it taken out gradually over time (over 200 of them). While it's actually just one web app, conceptually, it's two. There's one side which is an administrative side, and another for the general public. Some servlets are used by one side, other servlets are used by the other. They all use the same database, and share a lot of the same objects and data, however the user names and passwords are in different database tables. Also, the public side can be used anonymously (no need to log in). Login mainly gives the public side the ability to store preferences so that it doesn't need to be re-entered and keep track of history. I've been going over the realm documentation, and it's a little confusing. I think that I'm actually going to need two realms, one for each side (remember that they use different tables). I'm not exactly sure how to set that up. I'd like to use a DataSourceRealm, using the DataSource I've already set up, however I've also got the problem that the programmers who set this up stored the passwords UNIX/Linux style with a Java implementation of crypt(3), which doesn't seem to be one of the options for MessageDigest. I hope I'm wrong about that. Given how common it is in the UNIX/Linux world, I'd think that would be a good one to have (and please don't tell me that it's not that secure -- that's not the point -- this is a compatibility issue). Does this mean I'm going to need to write my own custom realm? That looks fairly confusing too. Can someone please point me at a good overall strategy for how to tackle all of this, given these constraints? I've only spent a few hours trying to go through the docs but I'm feeling a bit overwhelmed and really need some perspective.
Re: Load balancer (proxy?) problem.
Rainer Jung wrote:
To simplify your research a little bit: you mentioned you switched
cookies off in order to use the jsessionid URL parameter to log the
session IDs.
If you keep cookies on, then you can also log the value of the
JSESSIONID cookie by using the %C syntax of Apache's CustomLog.
Look at
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats
Something like %{JSESSIONID}C should work.
If you want to track, whether a new session cookie has been set (because
the old one was invalid), you can add e.g.
\%{Set-Cookie}o\
Thanks. That will come in handy.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Load balancer (proxy?) problem.
We're using LVS for load balancing to three separate Tomcat 6 servers. We do not have session replication. We do use sticky load balancing, or it wouldn't work. The problem is, we're having some customers, specifically people in parts of Australia and Malaysia, on wireless ISP's who are coming at us from different IP addresses depending upon whether the protocol is http or https. Our application switches between them based upon whether there is sensitive data in the page or not. Obviously, this means when they switch from the first one to the second, the load balancer doesn't realize they are the same browser and so it can, and frequently does, send them to a different server. We've verified this by getting them to disable cookies so that the jsessionid shows up in the logs. The same jsessionid shows up in the access log on one server and the ssl log on another server, with a different IP address in each log. They swear they aren't using proxies. I'm not sure I believe them. Is it possible that their ISP could be redirecting ports 80 and/or 443 through a proxy without the users browser being configured to do so? Is there some other reason why they could be hitting us from the same browser with two different IP addresses based upon using http or https? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Load balancer (proxy?) problem.
Mark Thomas wrote: Any reason you can't load balance based on the JVM route in the session ID? Other than not being aware that it could be done or how to do it, none that I know of. Normally, we use cookies for the session id. Can LVS look at the session id in a cookie? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Load balancer (proxy?) problem.
Mark Thomas wrote: Don't know. Never used it. Look for something in the docs around layer 7 load-balancing and/or cookies. If you are using https then your SSL will have to be terminated at the load-balancer otherwise you won't be able to see the session cookie or url. Apparently LVS doesn't look at any layer higher than the transport layer. LVS does have the ability to mask the incoming IP's so that everything coming from the same network relative to that mask goes to the same server. This will work as long as the proxy servers for the ISP are all on the same network, relative to the mask we set in LVS but if they are on different networks, we still break. It also reduces the effectiveness of the load balancer, which I don't like. I have always hated web proxies but until now, it was as a user due to consistently reduced performance as well as reliability problems. Now it's as a web server admin. I hate them more than ever. I really don't understand why ISP's can't provide persistent proxies for ports 80/443. I don't even have a way to track down the ISP's to complain about this. It's just wrong. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Load balancer (proxy?) problem.
André Warnier wrote: Bill Davidson wrote: ... Our application switches between them [HTTP or HTTPS] based upon whether there is sensitive data in the page or not. So I guess that if you did not do that, you would not be having this issue. Feasible ? Non-trivial. Also, there is resistance to making everything https due to performance concerns. I've also been doing some more in depth analysis of the logs, and I'm finding some cases of IP's jumping around for the same session id even when not switching protocols. I'm not even entirely sure it's proxies anymore. I'm back tracing some of these groups of IP's and sometimes they're not even for the same ISP. I've found mixes of AOL and Comcast as well as mixes of Comcast and SBC. Weird. I'm starting to worry that we're generating non-unique session id's or that there could be hackers trying to hi-jack people's sessions. More research to do - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Confused by mpm/mod_jk
Rainer Jung wrote: IfModule mpm_worker_module StartServers 2 MaxClients 256 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 32 Usually MinSpaceThreads and MaxSpareThreads having a multiple of ThreadsPerChild makes it easier understandable, what the numbers mean. Scaling up and down is always done in increments of processes, each having ThreadsPerChild threads. OK. I changed MinSpareThreads to 32 and MaxSpareThreads to 96 and left the others as is. workers.properties: worker.tomcat1.type=ajp13 worker.tomcat1.host=127.0.0.2 worker.tomcat1.port=8009 worker.tomcat1.connection_pool_size=150 Delete the connection_pool_size. Done. worker.tomcat1.connection_pool_timeout=600 you need to set connectionTimeout for the Tomcat connector to 60 then. Done. server.xml: Connector port=8009 protocol=AJP/1.3 address=127.0.0.2 redirectPort=443 maxThreads=150 / The 150 threads do not make a good fit to your MaxClients of 256. Increased to 256 to match MaxClients. I'm going to be hit with a traffic storm (many thousands of simultaneous connection attempts in a few minutes) in a few days, and I'm thinking I should make sure I've got this right. You need to do stress testing in order to find out, what the correct sizing is. If your application can stand the load and is very fast/lightweight, then you could manage more than 1000 requests/second with three Tomcats without ever reaching 256 MaxClients per Apache. If your application gets slow, then you might not be able to server 50 requests/second. Play around with the above formula. Not sure what the correct sizing is yet. However, we got the storm today and all went well. At one point ipvsadm -L -persistent-conn was reporting active connections in the 250-300 range and over 1500 inactive connections for all three servers. Nothing broke. The web servers never seemed to be heavily loaded. Only one of the three ever had a load average over 1. The database was loaded but not to the point of being scary. Obviously, I've still got some homework to do. Thank you so much for your help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Confused by mpm/mod_jk
Christopher Schultz wrote: Yes, most TCP/IP stacks use 127.0.0.1 as a special-case that avoids most of the real stack and instead uses a kernel buffer as the data transfer mechanism. I just tried to benchmark my own system localhost versus a DNS name that resolves to an IP address handled on the same machine. The results of downloading a 32MiB file 100 times using each address were the same. So, either my previous statement is invalid or my Linux kernel is smart enough to know that the same type of localhost optimization can be performed when the destination IP is on the local machine. Well, at least it's a security thing then. Even if the firewall somehow got opened up, Tomcat is still only accessible from outside the box by going through httpd first. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Confused by mpm/mod_jk
I'm trying to understand mpm_worker MaxCLients and it's relationship with mod_jk connection_pool_size. Here's what I've got at the moment: OS: Red Hat 5.2 Server httpd: 2.2.11 tomcat-connector: 1.2.28 tomcat: 6.0.18 Java: 1.6.0_13 httpd-mpm.conf: ListenBacklog 2048 IfModule mpm_worker_module StartServers 2 MaxClients 256 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 32 MaxRequestsPerChild 0 /IfModule workers.properties: worker.tomcat1.type=ajp13 worker.tomcat1.host=127.0.0.2 worker.tomcat1.port=8009 worker.tomcat1.connection_pool_size=150 worker.tomcat1.connection_pool_timeout=600 worker.tomcat1.socket_keepalive=1 server.xml: Connector port=8009 protocol=AJP/1.3 address=127.0.0.2 redirectPort=443 maxThreads=150 / Also, I've added these to /etc/sysctl.conf # increase the maximum number of TCP connections. net.core.somaxconn = 2048 net.core.netdev_max_backlog = 1024 I've got three separate boxes running their own httpd/Tomcat, load balanced with LVS so total connections is actually 3x of what is indicated above. I'm feeling like MaxClients is a bit low, but I can't seem to satisfactorily articulate why. I'm going to be hit with a traffic storm (many thousands of simultaneous connection attempts in a few minutes) in a few days, and I'm thinking I should make sure I've got this right. I went through it maybe 8-10 months ago but that was long before I put these systems into production. I probably should have gone through it again a month ago but didn't think to. I'm also contemplating increasing connection_pool_size maxThreads (I'm pretty sure those have to be equal) since my database can handle up to 1000 simultaneous connections and as it is, I've got a maximum of 3*150=450 Tomcat threads that can access it at any given time. Any useful advice on this would be appreciated. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Confused by mpm/mod_jk
Rainer Jung wrote: Hey great, someone using recent version :) I've been trying to stay current with the stable releases since upgrading the app from httpd 1.3 and Tomcat 3.2.4 last year. I usually wait a couple weeks to a month and watch the mailing lists after a release to make sure nothing major snuck through QA. ListenBacklog 2048 Wow. I'm just guessing on most of these things. I suspect I copied that from the httpd 1.3 + Tomcat 3.2.4 configuration, as I did with a lot of the other numbers. I didn't create those old configs. I just came in and tried to get the app working on Tomcat 6 and httpd 2.2 (and with the help of Brittain Darwin and the people on this list, I succeeded). Delete the connection_pool_size. Connection pools in mod_jk are local to httpd processes. Each process can only use as many connections, as it has threads to process concurrent requests. In your configuration this is 32. mod_jk asks httpd when starting about this number and automatically sets its pool size to the number of threads per process. You'll never need more. Only if you have very good reasons, that you want to lower this, you can configure a smaller number. Usually you don't want to do this. please do also have a look at the docs page on timeouts for mod_jk. I will do that. The 150 threads do not make a good fit to your MaxClients of 256. If your Apache is mainly forwarding requests to Tomcat, then it doesn't make much sense to allow 256 parallel connections to Apace, but only 150 on the backend. That will result in some Apache processes being fully connected (32 connections) and some other not able to grow their connection pool to the full size, because they get errors when trying to connect. Interesting. httpd is mainly connecting to servlets but those also request images, javascript, style sheets and applets that get served directly by httpd. Are the Apaches connected to each Tomcat, or only to their Tomcat? Only to their own Tomcat. I even do the connection on the loopback for security and (I hope) performance. If you separate your design into 3 disjoint Apache/Tomcat pairs, then you need to educate your LVS about correct session stickyness. Already done. I'm pretty sure this setup wouldn't be working at all in production if we hadn't since we don't have session replication (yet). Thanks for the advice. I'm still digesting some of it and I'll be looking at that documentation again. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] of very off topic marketing question
Peter Crowther wrote: From: André Warnier [mailto:a...@ice-sa.com] Peter Crowther wrote: I'm also particularly amused by the topmost set of bars in figure 2, given how proud the perl-ites are of their RE library and performance ;-). You didn't expect for a minute that this would remain unanswered, did you ? First, the perl-ites would answer that the comparison being with PHP, it is of little relevance. sigh. Quite. One of these days I'll learn to read... apologies. Heh. Yeah. PHP's PCRE != Perl's RE. More off topic: Perl's RE performance is usually not realized by most Perl programmers because from what I've seen, most don't bother to pre-compile their regular expressions. I've seen RE intensive Perl scripts achieve 20x speed-up simply by pre-compiling the regular expressions with the qr// operator before applying them hundreds of thousands of times on large data sets. There's a reason I use Pattern.compile()/Pattern.matcher()/ Matcher.matches() etc. when String.matches() would have done the job. It might be interesting to do a speed comparison test between the Perl, PHP/PCRE and Java RE libraries. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fun with the JVM crashing.
Rainer Jung wrote: In case you only want to exclude few methods from compilation, -XX:CompileCommand=exclude,com/myCompany/servlets/sales/blah/some,method will do it. Since we put this change into production, we haven't seen the problem. Thank you so much. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hello
Okey Kene wrote: Am using windows vista and i wish to know what version of apache tomcat to download. Are you planning to write webapps or are you only wishing to deploy webapps you've acquired from other sources? If you wish to learn to write JEE webapps, then I recommend the latest version (currently 6.0.18). If you wish deploy existing webapps, then I suggest you check with the providers of those webapps as to which is the best version. In most cases, the latest version should work fine. You should also read the documentation. Books don't hurt either. I like Tomcat The Definitive Guide by Brittain and Darwin for Tomcat administration and Head First Servlets JSP by Bashram, Sierra Bates as an introduction to writing Java web apps. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP vs HTTP connectors?
Eric B. wrote: I was listening to a webinar on spring source by Filip Hanik Mark Thomas regarding tuning Tomcat for production in which they indicate that the Http connector is recommended vs an AJP connector (http://www.springsource.com/node/555). I downloaded this webinar and watched/listened to it yesterday. It was excellent. Thanks Filip and Mark. I found it very informative and plan to use the things I learned from it. The only downside is that since the site requires you have to give your info, you get marketing email from SpringSource. I should have given a bogus email address but I didn't think to. We don't use Spring here. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL/HTTPS forwarding under Apache + mod_jk + tomcat
Bill Davidson wrote: André Warnier wrote: By the way, the reason why I can't try it right now is that I just don't have the application to try it with. So whatever I mentioned before (but which apprently so far seems ok) was purely by attempting to understand the documentation. Beware. I tried it today. I disabled my cookie hack and set JkExtractSSL to off. It seems to work fine. Obviously, I want to do a lot more testing but initially, it seems to look good. There's a problem. Unfortunately, we have a servlet in our app that calls request.isSecure() to make sure that it's on a secure connection and because of JkExtractSSL off it doesn't know whether it's on a secure connection or not. request.isSecure() will always return false because mod_jk no longer tells it anything about SSL. So I'm back to hacking the cookie. I really want to just get rid of httpd and run Tomcat standalone. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fun with the JVM crashing.
Rainer Jung wrote: You can track compilation with -XX:+PrintCompilation. [...various other options...] Wow. I never realized you could do stuff like that. Neat. Thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should I use the -server switch?
Caldarale, Charles R wrote: Most of the 64-bit Sun JVMs come only in -server mode, no -client version. Run java -version (without the quotes) to see what the default mode is. Checking that... $ ./java -version java version 1.6.0_11 Java(TM) SE Runtime Environment (build 1.6.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode) So no need for the switch, since it's already doing that. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fun with the JVM crashing.
Caldarale, Charles R wrote: Only if that shows up repeatedly. It does. I'm thinking that the JVM shouldn't be getting SIGSEGV's. You're right about that. However, it could also be an OS or hardware problem. You might want to run some serious memory tests on the box, just to eliminate the latter. Does this particular system use ECC memory, or just plain old parity-checking DIMMs? Not sure. However, it has happened on three different boxes, always with the same CompileTask mentioned. You can also try either moving up to the recently released JDK 6u12, or dropping back to 6u7. Lots of changes went in at 6u10, and something might still be broken in there. The C2 compiler is an extremely complex beast. I'll try that. BTW, it also happened with 6u10. I'm wondering if -Xint might help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fun with the JVM crashing.
Caldarale, Charles R wrote: Major changes went in between 6u7 and 6u10. Maybe I should try reverting to 6u7? I'm wondering if -Xint might help. Only if you want performance to go into the toilet - that's interpreter mode, also know as really, really, abominably slow. I was thinking it might make the CompileTask issue go away. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fun with the JVM crashing.
Bill Davidson wrote: Caldarale, Charles R wrote: Major changes went in between 6u7 and 6u10. Maybe I should try reverting to 6u7? Dammit. Looking back through my old hs_err*.log files, it also happened with 6u7. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat] [daemon] java.lang.OutOfMemoryError unable to create new native thread
Christopher Schultz wrote: What about forwarding X through the tunnel instead? I've tried that and found it to be unusably slow. Just using Cygwin/X though. I'm not sure about those fancy light weight X compression systems. I really would like to be able to run these kind of tools across a firewall. I can't believe there are no provisions for it. It has to be something that a lot of people want to do. If I can run Oracle connections over an ssh tunnel with good performance, it seems like I should be able to do something like jconsole data too. RMI's random port thing is really annoying. It seems like there ought to be some way to specify all ports involved. Whomever designed it apparently didn't give any thought to working across firewalls. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Should I use the -server switch?
Tomcat 6.0.18 JVM: Sun 1.6.0_11 64-bit for Linux What does this switch really do anyway? The name implies it's for server programs but I can't find a good explanation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fun with the JVM crashing.
I've submitted this to Sun a few times. No response. I was hoping someone here might have an idea of what to look for. Tomcat 6.0.18 RedHat 5.2Server Sun JVM # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b68e6a1db57, pid=10229, tid=1103006016 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x564b57] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x4bfe5c00): JavaThread CompilerThread0 daemon [_thread_in_native, id=10244, stack(0x41ae8000,0x41be9000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x . Current CompileTask: C2:2525 com.myCompany.servlets.sales.blah.some.method(Lcom/myCompany/servlets/someClass;Lcom/myCompany/servlets/otherClass;Lcom/oreilly/servlet/ParameterParser;)V (425 bytes) .. - I'm wondering if that CompileTask is what's causing the problem. I'm thinking that the JVM shouldn't be getting SIGSEGV's. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle database calling the web app?
Juha Laiho wrote: However, have you actually measured how much load it would put to various pieces of your system to not cache this data, but just fetch it from the DB more or less each time it is needed? We currently have the ability to turn the caching on or off. We generally only turn it on when we anticipate a massive traffic storm coming to our site (caused by new highly in demand items going on sale). At the moment, once we turn the cache on, the cached data only gets updated by turning caching off and then back on -- which is something we don't like to do when we are getting thousands of hits per minute. While I'm not aware of exact measurements, the system can handle major traffic loads much better when we have the caching on. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle database calling the web app?
Ken Bowen wrote: Whoops, hold that. This is ok for outbound. For inbound, it seems Jboss is needed: http://activemq.apache.org/jboss-integration.html I'm not sure I understand how that says JBoss is needed to do inbound communications. There is a page on configuring Tomcat: http://activemq.apache.org/tomcat.html I'm finding the ActiveMQ docs less than obvious. I'm not entirely clear on what it is I'm trying to do when setting this up. I'm confused about whether I need to run ActiveMQ as a stand alone process with a connector to Tomcat or whether I can run ActiveMQ inside Tomcat (is that what they mean by embeded?). The latter sounds better. I've had no luck finding an Introduction to setting up ActiveMQ with Tomcat for people who've never set up JMS before tutorial. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Oracle database calling the web app?
Is it possible to set up a callback like situation so that a trigger in an Oracle 10g database can call a method in a currently running webapp that's running in Tomcat 6? My situation is that I want to cache some infrequently changed database data in memory but when that data does change in the database, I want the web applications, running on multiple servers, to immediately pick up the change. Right now, one idea I have for this is to have the database trigger create a file in a file system that's shared by the database server and the application servers and have the web apps check for the existence of this file to know whether to update the cache. It feels ugly and means hitting a networked file system a lot but it seems like it should work and it seems like it should not be as bad as hitting the database constantly for something that doesn't change very often. I'd rather have the database send a message somehow to the web app that it needs to update its cache of the data. Any suggestions? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle database calling the web app?
Mark Thomas wrote: 1. JMS? I thought Tomcat didn't support JMS. Am I wrong about this? 2. Call an reload servlet from the database? Sounds slightly painful but at least it's event driven. 3. Drop the immediate update requirement and poll a data changed flag in the db every x seconds? Still not event driven like I'd like but it might be acceptable. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle database calling the web app?
Edward Dowgiallo wrote: Support for what you want to do is actually a feature in Oracle 11g. For Oracle 10g, you want to look at the publish/subscribe support which is part of advanced queueing. The documentation is available online at http://otn.oracle.com. Is this the book I should be reading? Oracle Streams Advanced Queuing User's Guide and Reference - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle database calling the web app?
Bill Davidson wrote: Oracle Streams Advanced Queuing User's Guide and Reference Looking through that, it looks like it uses JMS to send a message back to Java. Being on Tomcat, that's a problem. Some searching shows I may be able to use OpenJMS or ActiveMQ to get JMS in Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Communicating between webapps
Darryl Pentz wrote: I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container. I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container. Since you're running in the same JVM, I'm not sure why you can't set up some sort of observer-subject scheme (kind of like ActionListener if you're familiar with that) so that the apps can just access each other's object directly. You can set up a singleton object to register the observers between webapps. Just be sure to synchronize properly. It should be pretty simple to do and dramatically more efficient than RMI/SOAP or really anything over an IP connection. It's hard to beat direct memory access for speed. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Darryl Pentz wrote: You would think so but it isn't that easy. Which is good to some degree, because that would seem like a scary security vulnerability. Nevertheless, besides that, Tomcats classloader hierarchy also prevents this mechanism. So if I'm understanding you correctly, different webapps use different class loader instances and so the singleton is actually instantiated separately for each class loader? If that's the case then yeah, that would blow a big hole in that idea. I didn't realize it was like that. I guess it's a good thing I haven't needed to do this so far. As far as security, presumably the OP would be in control of both webapps so that should be manageable if it was possible in the first place, which it apparently isn't. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Server Maintenance Across Timezones (global)
My company's main webapp is used around the world (Europe, North America, Australia, etc.). We're using Tomcat as our app server and Oracle (10g) for our database. When we want to do an upgrade, that usually involves DDL changes to the database as well as corresponding changes to the webapp which means we have to make our users log out so we can shut down the app, update the DDL and restart the updated webapp. The changes are interdependent. It's all or nothing. This was not a big problem when we were just doing business in the U.S. We'd do upgrades late at night when nobody (or hardly anyone) was using the system. The problem now is that late at night here is middle of the day in other places and downtime in the middle of the day is a real problem. Our customers use our app to run parts of their business so downtime in the middle of the day is very very bad. They understandably don't like telling their customers: I'd like to help you but I need to wait for the Americans to upgrade their systems. I'm not sure how to deal with this. I've been trying to think of a way to use multiple servers and multiple databases but that seems like a synchronization nightmare. Losing data consistency is not an option. I'm sure that plenty of others on this list have had to deal with this problem. Any suggestions? How have others dealt with it? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Server Maintenance Across Timezones (global)
Paul McGurn wrote: Segregate, geographically, your customer base's target infrastructure. The way they do this is by tying their customers to a specific cluster of their cloud, and then everything that customer does in the application is tied back to that cluster. The layer of redundancy (on top of being a cluster of course), is having a hot failover infrastructure that is synched with the production infrastructure at whatever feasible cycle works for the amount of data. By doing this, they can then schedule maintenance windows geographically, to ensure that impact is low no matter where the customer is. Indeed. In your case, this would likely require some effort in architecting the data storage part of things to be partition-able to some extent, but this would really be maintaining what would be the effect of multiple datacenters/clusters/clouds. The main difficulty with this is consistency. Many parts of our data are tagged with dynamically generated id's (order id's for example) that are printed out and referenced by our customers, and even their customers. Running on multiple databases allows for the possibility (at this point certainty) of generating duplicate ids across different regions. This could result in a lot of confusion, particularly for support calls. We may need to learn to live with that but I still am not crazy about it. This may be the only reasonable way to do this without completely re-architecting our app (which is not really doable any time soon). - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Server Maintenance Across Timezones (global)
John5342 wrote: I get around my the same kinds of problems by keeping all the layers of the web app seperate so that i can swap them out one at a time and create a near seemless upgrade. The layers in my web apps are: 1 The web interface. 2. The application logic. (this may itself be several layers in itself if the app is complicated) 3. The database access layer. 4. The database. [...] Hope what i said is useful. I think it will be useful when we get to the point of redesigning the app from scratch. It's a bit tough to replace the data access layer of a large complex app that's been around for a long time though. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbies, becareful of pure cookie based magic... theres a few gotcha's
Johnny Kewl wrote: Going to add this to my other no no's like those people that insist on building entire site only in JSP pages... I'm not sure I get your meaning here. Do you mean really just JSP's with no Java classes (beans or otherwise) that aren't in the JSP's themselves? Yeah. That would be bad. I've seen it too *cough*Oracle Applications*cough* - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ignorance about some things.
Gregor Schneider wrote: No, in fact the 64-bit-jvm is able to adress (thus use) more memory than on 32-bit-jvm. just make sure that a 64-bit-jvm (java-virtual-machine) is installed. Actually, in machine terms, pointers in a 64-bit system are twice as wide and thus take up twice as much space. Every reference is a pointer. Depending upon the machine implementation, even loops and conditionals could possibly use 64-bit pointers as well so those would use more memory if they did. So yes, a 64-bit system will always use at least somewhat more memory than a 32-bit system that does the same thing. This is not to say that there couldn't be a memory leak in the 64-bit JVM that doesn't exist in the 32-bit JVM. I'm just saying that all else being equal, the 64-bit version will use more memory -- because it has to. I remember when I was first playing with 64-bit systems in the mid 1990's (C/C++) and was surprised to find that many programs actually ran slower when recompiled for 64-bits. One of the reasons for that was because they're moving around more memory just to move their pointers around. Unless you have big memory and need big memory, or you're doing a lot of arithmetic with 64-bit integers, it's usually best to stay with the 32-bit version. It will usually be at least as fast if not faster and use less memory. Of course, if you need the big memory, or lots of 64-bit arithmetic then you need it so you go with 64-bit. As for the OP, you'll want to play around with -vmargs settings to your JVM. -Xmx is the obvious one. -XX:MaxPermSize is another less well known one that can help in many cases. PermGen space is one of those sneaky things they don't tell you about. You can set -Xmx really big and still have memory problems because not enough of it is available to PermGen. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another confused person trying to get jconsole to monitor tomcat.
On 21 Aug 2008, at 09:25, Mark Thomas wrote: Add some logging to your firewall configuration to see what is being dropped. Dominic Mitchell wrote: That should help, but it's likely to be a different port in use each time. Because JMX uses RMI by default, and RMI uses two ports: a fixed port to initiate the connection and then a secondary (random) port for data transfer. This is a real pain to get working. Mark Thomas wrote: There are tricks you can play with iptables to allow that. The down-side is that it isn't as secure. Thanks everyone. Is this random port opened by the server side (Tomcat) or the client side (jconsole) or is there some other program running in there to make my life difficult? Is there a way to configure Tomcat or jconsole, as applicable, to use the same specified second port every time? What are the tricks that can be played with iptables? I'm guessing they involve opening up a range of ports? I'll still be limiting it to one or at most 2-3 IP addresses. Once I get SSL and authentication going, that may be secure enough. BTW, I'm not real good at iptables and this is the first time I've tried to play with JMX. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another confused person trying to get jconsole to monitor tomcat.
Tim Funk wrote: An easy kludge is to run jconsole locally on the server and send the display to yourself. ssh -Y yourserver (or ssh -X server YMMV) $JAVA_HOME/bin/jconsole pid No iptables tricks needed. I'm running the client on a Windows machine. I did try Cygwin/X and an ssh tunnel with Putty. The performance was bad enough to be effectively unusable. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another confused person trying to get jconsole to monitor tomcat.
I've been through the docs. I've been through Google. I can't seem to figure this out. Server: Tomcat 6.0.18, JDK: 1.6.0_07, Redhat Server 5.2 Client: jconsole from JDK 1.6.0_07 on Windows XP I've got all of these in $CATALINA_OPTS and they do show up in the java command line when I run ps: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false The Redhat server is running iptables and disallows most things that aren't 80/443. Any other ports that are needed are generally opened up only to specific IP's. I've opened up the JMX port specified above on the Linux firewall: iptables -A INPUT -s myClientsIp -p tcp -m tcp --dport 12345 -j ACCEPT I run jconsole: C:\PathToJava\binjconsole myServer.myDomain.com:12345 It can't make the connection. I've got a feeling it's something to do with the firewall. I've seen some stuff that suggests that there's another unspecified port opened up but it didn't really make sense to me. Note that the server and the client are at different facilities connected over the internet which is why I eventually want to get it going with authentication and SSL but I can't even get this simple insecure version of the connection to work. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using tabbed browsers causes session sharing
Robert Dietrick wrote: Why would you want the same person logged in twice with different accounts? As a developer of a web app that has both admin and regular user roles, I want to do this all the time. The admin roles can change things in ways that affect the regular user's view. I want to see how things change without having to log out and log back in as a different user. The way I deal with it is to use Firefox for one and IE for the other. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using tabbed browsers causes session sharing
Christopher Schultz [EMAIL PROTECTED] wrote: You could use separate tabs in the same browser if you were to disable cookies on your browser (and you have correctly encoded your outgoing URLs). David Rees wrote: Yep, this is probably the best way to do it. Just keep in mind that if you copy links it will have your session id in them. I think it's easier to just use two browsers. I have to make sure everything works in IE and Firefox anyway so it's just as well that I'm using both on a fairly regular basis. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spam Score
Patrick Markiewicz wrote: What is the tomcat mailing list spam score, and why am I unable to send my email to post a question? You just posted a question. I don't know what you mean by spam score. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk on the loopback?
Assuming httpd and tomcat are running on the same machine, would it be best to run the mod_jk connection on the loopback rather than the primary ethernet? Any disadvantages to the loopback? It seems like it might be more secure since other machines would not be able to make a direct connection tomcat at all. Am I missing anything obvious? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache and Tomcat
Stuart Caldwell wrote: I know this may sound naïve but is it possible to have tomcat and apache running off the same port - 8080. I have iis running on port 80 and do not have another server to install apache and tomcat. TCP only allows one listener per port-IP combination. It really doesn't make sense to have more. How would the OS decide which listener gets the request? Are you using Apache as a front end to Tomcat using mod_jk or some other type of proxy? If so, do you really need direct access to Tomcat? I use Apache as a front end and route servlet/jsp requests to Tomcat via mod_jk. Apache is running on 80 but I've disabled the 8080 connector to Tomcat. There's no need for it since I can access Tomcat through Apache. If you do need direct access to Tomcat for some reason, is there some reason you can't put it on another port like say 8081 or something? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL/HTTPS forwarding under Apache + mod_jk + tomcat
André Warnier wrote: By the way, the reason why I can't try it right now is that I just don't have the application to try it with. So whatever I mentioned before (but which apprently so far seems ok) was purely by attempting to understand the documentation. Beware. I tried it today. I disabled my cookie hack and set JkExtractSSL to off. It seems to work fine. Obviously, I want to do a lot more testing but initially, it seems to look good. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL/HTTPS forwarding under Apache + mod_jk + tomcat
Rainer Jung wrote: André Warnier wrote: And, again in other words, if this parameter was set to Off, and Tomcat generated a new session and a JSESSIONID session cookie for this session, that the cookie would thus not be marked secure ? Didn't try this. What does your tests say? Oooh! I may want to try this. I may not have needed to change my app at all. If your own knowledge about secure / non secure differs from the one of httpd (e.g. you use an ssl accelerator in front of httpd) and you want to present your own idea of secure / non secure via mod_jk to Tomcat, you can set JkHTTPSIndicator to the name of some httpd environment variable, and then set the environment variable depending on details of the request via mod_setenvif or mod_rewrite. But if you simply want to drop all ssl info, setting JkExtractSSL to off is right. Interesting. I'm wondering if my old Apache 1.3.34+ssl Tomcat 3.2.4 combination involved any knowledge by Tomcat of Apache doing SSL? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from a very old Tomcat to a new Tomcat.
Christopher Schultz wrote: Yes, but the OP didn't say whether no changes were made to the original code (or configuration) when moving between Tomcat versions. Until the change to the login servlet for the cookie, there were no changes to the app's code. It's even still being compiled against TC 3.2.4 libraries with Java 1.4.2. Obviously, I had to jump through a few hoops on the TC 6 configuration since it has changed considerably since 3.2.4. I'm not sure how much of those issues were due to the app not doing things in standard ways and how much was changes between TC versions. It's tough to tell. The OP was using TC 3.2.4 (ancient!) and it might not have been setting the secure flag on that cookie. I believe this to be true. The cookie must be called JSESSIONID, and the value must be the id of the session. So, you can just do something like this: response.addCookie(new Cookie(JSESSIONID, ~ request.getSession().getId()); That is what we did. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from a very old Tomcat to a new Tomcat.
Bill Barker wrote: This is correct. TC 3.2.4 never set the secure flag on that cookie, and TC 3.3.2 would only set it if you enabled an option in server.xml. This feature of TC is only on TC 4.0 and higher. Thank you for confirming that. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from a very old Tomcat to a new Tomcat.
Christopher Schultz wrote: Did you change Tomcat code, or your own code? Our own code. We have an explicit login servlet that handles checking the login/password against values stored in our Oracle database. Okay, so it sounds like you are using your own. Is there any particular reason you are not using the built-in container-based security mechanism? I don't know. I didn't design it. Was that container based security available in Tomcat 3.2.4? Those performance concerns are certainly valid. My experience has shown that most all-HTTPS sites have the SSL handshake as the most expensive part of the transaction -- sometimes even including (localhost, non-encrypted) database activity. There are ways to speed it up, but they are expensive. It's cheaper to buy more boxes ;) Which we're doing. One of the nice things about doing this new Tomcat is that I'm doing it on a new box with a newer version of Linux, more CPU's (dual quad-cores), more RAM etc. Eventually, I want to get into Tomcat clustering, for load balancing, fault tolerance and fail over. Just remember that sending JSESSIONID cookies in the clear means that sessions can be hijacked. I know. I totally understand. Just try to move to a more secure stance over time. It's the best you can do. Agreed. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from a very old Tomcat to a new Tomcat.
Christopher Schultz wrote: Yep. It's part of the servlet specification. Maybe as you move forward, you could look into using that and reduce the amount of code you have to maintain. Note that TC container-managed authentication does not allow drive-by logins (that is, logins that didn't result from the request for a protected resource). Basically, no unexpected logins, which kind of sucks. Securityfilter, available on sourceforge, provides container-managed-auth-style authentication and authorization and gives you some additional options not provided by TC. Feel free to check it out. Thanks for all the advice. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http after upgrade to Tomcat 6
Johnny Kewl wrote: Bill... Just lose the FORM authentication, replace it with DIGEST, or even BASIC I think all your problems will go away. I'm not exactly sure what you're saying. Are you saying that I shouldn't be authenticating through a form? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http after upgrade to Tomcat 6
Bill Davidson wrote: I'm confused so I'm not sure what I say below makes sense. If I'm reading these posts correctly, the cookie is issued by the front end (which is Apache web server). Since it is created on an https session, it is being marked as secure. When browser switches to a non-secure page on the same site, that cookie is not passed because it is a secure cookie. I was right about one thing: I was confused. Apparently it was actually Tomcat creating the cookie. I've found a usable workaround. I'm having my login servlet create and set the cookie (without setting it to secure). That seems to have made the problem go away. I was trying to get away without changing the app but this is a pretty minor change. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http after upgrade to Tomcat 6
BTW, I forgot to thank everyone for helping me to understand what this problem better. Understanding that the cookie was being created by Tomcat with the secure flag and that the flag was causing the problem was the key. Thanks everyone. --Bill Davidson - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
