Re: Parallel Deployment: Get Context Version #
On 11/08/2011 02:55, Jonathan Rosenberg wrote: Two benefits: 1) Allows incompatible upgrades. 2) Allos existing sessions to complete. Parallel deployment does allow existing sessions to complete. Only new sessions are directed to the newest application. Are you seeing different behaviour? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Multiple Tomcat Servers connect to IIS
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander, On 8/10/2011 8:12 AM, Alexander Diedler wrote: my uriworkermap.properties /manager=worker1 Mapped /manager /manager/*=worker1 /docs=worker1 /*=worker1 /go/*=worker1 /go=worker1 /show/*=worker1 # Mapping all URI which end with a common suffix: *.jsp=worker1 /manager=worker2 Re-mapped /manager This re-mapping appears to happen for all URIs. I've never worked with IIS -- can you specify a uriworkermap.properties for each virtual host? I think that's what you want to do, but it looks like you're configured everything in a single set of files, here. Read the docs... ;-) It appears that for IIS and isapi_redirect (and differently from Apache+mod_jk), there is only one uriworkermap.properties files, being used for all the IIS virtual hosts (and its single path is in the Registry under a single key). However, in the (single) uriworkermap.properties, there is a way to specify the hostname, in addition to the URI being proxied. So you can actually have things like : /serverA.company.com/app1/*=tomcat1 /serverB.company.com/app1/*=tomcat2 I never tried it, but according to Alexander it works and solves his problem. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 6.0.20 Cleanup after application crash
You may want to check first which keep alive settings they have for the whole chain. If one of them happened to be close to 15 minutes, that might be a strong hint. Another tool is netstat, to see exactly in which TCP state these persistent connections find themselves in. (another bad sentence, just keeping in style here). Dante Bell wrote: Hi Chris, I did indeed read and digest Mark's email and talked to the vendor about that issue. The stack trace on the old blog post is from the one Mark was helping out with (man, that was a really bad sentance!). This is a different issue :( I don't have a stack trace and I don't have access to the lab they are running these tests in. I've requested the stack traces when this happens, but haven't received those yet. Your question about 'crash' is valid and the explanation I received was that the load test application crashes. That's all I have at this time from them. I'm helping them from a dark, distant planet and only see the things they want me to see ;) Weirdly, it doesn't sound like TC is dead from what they are telling me, after 15 minutes it starts serving up db responses! Yes, they are using mod_jk. On 08/10/2011 12:55 PM, Christopher Schultz wrote: Dante, On 8/10/2011 11:57 AM, Dante Bell wrote: We are seeing that after an application crash (customized load tester with minimal error handling so it crashes often) When you say crash, do you mean you get a stack trace in the logs and Tomcat stays up, or do you mean that you bring-down the JVM? If you bring-down the JVM, what is the error that is occurring (check hs_*.txt files laying around in the working directory for that)? that TC isn't releasing the connection for about 15 minutes. If TC is truly dead, then it's not holding connections at all. That would be the OS holding them. What makes you think they are not being released? What counts as released? I've reviewed some of the worker directives, but I'm really unsure as to which one or combination would shorten this interval significantly. Does that mean you are using mod_jk/mod_proxy_ajp? Good to have that kind of information. The Apache server still serves up static content, which makes me think that there isn't anything at the OS or Apache layer that is causing the connection to hang around (granted, this isn't an absolute and we are investigating these 2 components also). So you're using Apache httpd, too. Also good to know. We've done some minor TCP/IP tuning in the Solaris stack, and that has helped with other issues regarding heavy loads. On Solaris. If TC is the culprit, would we need to be setting the advanced connector directives such as: |recovery_options|4: close the connection to Tomcat, if we detect an error when writing back the answer to the client (browser) That depends upon what the errors actually are. Care to tell us about them? PS. Configs can be found at: http://bit.ly/pFIzO0 Sigh. You should look into template workers. Apache httpd MaxClients setting default is 256. Connector MaxThreads is set to 750, so Tomcat should have almost 3 times more than you need. Where do you see 750 stuck threads? I looked at your thread dump. You clearly have not read Mark's previous response on this list where he told you exactly what was happening: your webapp is killing itself with these SingleThreadModel servlets. This is not thread starvation due to configuration, this is thread starvation due to a poorly-implemented web application. Apache:* Apache HTTP Server Version 2.2 -- prefork with mpm *Tomcat:* 6.0.20 *JK Connector:* Same as whatever is bundled in with Apache 2.2 (from customer) *Solaris* Solaris 10 10/09 s10s_u8wos_08a SPARC Aah, here's all the configuration information. Description then context. Not the best term paper I've ever read. :( I think you mean prefork MPM. Apache httpd does not bundle mod_jk. Check your version. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: Multiple Tomcat Servers connect to IIS
Hello, Yes thanks, with adding the vHost Name it works with one exception. I cannot access the Manager App. I get a auth Window, the credentials are correct, but I do not get into the Manager App. Uriworkermap.properties: /manager=worker1 /manager/*=worker1 /docs=worker1 /*=worker1 /go/*=worker1 /go=worker1 /show/*=worker1 # Mapping all URI which end with a common suffix: #*.jsp=worker1 ##vHosts for Tomcat 7.0.19 /SiteB.xxx.de/*=worker2 /SiteB.xxx.de *=worker2 /SiteB.xxx.de /manager/*=worker2 /SiteB.xxx.de /manager*=worker2 Best regards Alexander -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 11. August 2011 10:30 An: Tomcat Users List Betreff: Re: AW: Multiple Tomcat Servers connect to IIS Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander, On 8/10/2011 8:12 AM, Alexander Diedler wrote: my uriworkermap.properties /manager=worker1 Mapped /manager /manager/*=worker1 /docs=worker1 /*=worker1 /go/*=worker1 /go=worker1 /show/*=worker1 # Mapping all URI which end with a common suffix: *.jsp=worker1 /manager=worker2 Re-mapped /manager This re-mapping appears to happen for all URIs. I've never worked with IIS -- can you specify a uriworkermap.properties for each virtual host? I think that's what you want to do, but it looks like you're configured everything in a single set of files, here. Read the docs... ;-) It appears that for IIS and isapi_redirect (and differently from Apache+mod_jk), there is only one uriworkermap.properties files, being used for all the IIS virtual hosts (and its single path is in the Registry under a single key). However, in the (single) uriworkermap.properties, there is a way to specify the hostname, in addition to the URI being proxied. So you can actually have things like : /serverA.company.com/app1/*=tomcat1 /serverB.company.com/app1/*=tomcat2 I never tried it, but according to Alexander it works and solves his problem. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org smime.p7s Description: S/MIME cryptographic signature
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
OK, I'm getting close. On the server side, I'm adding a Set-Cookie header containing the session id I want to use. The client emulator I am using has similarly been modified to add a Cookie header with the session id sent by the server, but sticky sessions are still not working. In the mod_jk log, there is a searching worker for partial sessionid reference that contains the correct session id, but .worker was not appended. In my workers.properties file, sticky_session is set to 1. The jvmRoute parameters in my respective Tomcat server.xml files are set to the workers identified in the workers.properties file as well. What do I have to do to append .worker to the outgoing session id? -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, August 09, 2011 5:09 PM To: Tomcat Users List Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 Rainer Jung wrote: On 09.08.2011 20:45, Lataxes, Karl wrote: Our clients cannot send or process JSESSIONIDs as they are not web browsers, but proprietary equipment running embedded software that sends HTTP POST messages to a servlet on our internal network. The servlet keeps track of sessions internally by assigning a session id which is contained within the HTTP request body. I believe my best solution would be to send an additional header containing the session id with the servlet response and using that for sticky sessions. I am working with our embedded software developers on sending this header back to the servlet during subsequent client requests to facilitate sticky sessions. I know I will probably have to go to Apache 2.2 to accommodate this, but that was something I expected. Are you aware of the fact, that a cookie *is* an additional HTTP header, namely the header named Cookie? So if you can set HTTP headers to values you can define, then you *can* send cookies. That was a much shorter way to get to the same conclusion as my earlier contribution.. :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 creating Swing GUI under Windows 7 64bit
-- Wiadomość oryginalna -- Temat: Tomcat 6 creating Swing GUI under Windows 7 64bit Data: Thu, 11 Aug 2011 16:18:29 +0200 Nadawca:Michał Wróbel michal.wro...@evolpe.pl Adresat:users@tomcat.apache.org Hi, I am currently struggling with a following problem: The system I use (Alfresco) provides a serverside javascript debugger. It's a Swing based window. I managed to run it under linux (when tomcat runs in X11 user session, although I can't find the way to display the same GUI when tomcat runs in Windows 7 64 bit. I tried following approaches: - Ticking 'Allow service to interact with desktop' Results only in: Caused by: java.lang.NullPointerException at sun.awt.shell.Win32ShellFolder2$1.call(Win32ShellFolder2.java:230) at sun.awt.shell.Win32ShellFolder2$1.call(Win32ShellFolder2.java:225) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:480) ... 1 more No effect on 'service interaction screen' - Providing logon details for my own windows account ( same effect as above ) - Running from catalina.bat catalina start with, and without jawa.awt.headless=false Results in headless exception: at java.lang.Thread.run(Thread.java:619) aused by: java.awt.HeadlessException at java.awt.GraphicsEnvironment.checkHGadlGss(GraphicsEnvironment.java:1 at java.awt.Window.init(Window.java:432) at java.awt.Frame.init(Frame.java:403) at javax.swing.JFrame.cinit(3Frame.java:202) at org.mozilla.javascript.tools.debugger.SwingGui.cinit(SwingGui.java:1 I've read about a successful attempt under Windows 7 32-bit So... do you know is it anyhow possible to run tomcat with Swing GUI under Win7 64-bit or is it a system limitation...? It's eaten 2 days and I'm starting to be a little despaired. thx from advance
Re: Tomcat 6 creating Swing GUI under Windows 7 64bit
P.S. I managed to run this Swing window on virtual windows XP machine, so this problem seems to be realted with Win7 64 bit. Any possible causes and workarounds on your minds? W dniu 2011-08-11 16:20, Michał Wróbel pisze: -- Wiadomość oryginalna -- Temat: Tomcat 6 creating Swing GUI under Windows 7 64bit Data: Thu, 11 Aug 2011 16:18:29 +0200 Nadawca: Michał Wróbel michal.wro...@evolpe.pl Adresat: users@tomcat.apache.org Hi, I am currently struggling with a following problem: The system I use (Alfresco) provides a serverside javascript debugger. It's a Swing based window. I managed to run it under linux (when tomcat runs in X11 user session, although I can't find the way to display the same GUI when tomcat runs in Windows 7 64 bit. I tried following approaches: - Ticking 'Allow service to interact with desktop' Results only in: Caused by: java.lang.NullPointerException at sun.awt.shell.Win32ShellFolder2$1.call(Win32ShellFolder2.java:230) at sun.awt.shell.Win32ShellFolder2$1.call(Win32ShellFolder2.java:225) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:480) ... 1 more No effect on 'service interaction screen' - Providing logon details for my own windows account ( same effect as above ) - Running from catalina.bat catalina start with, and without jawa.awt.headless=false Results in headless exception: at java.lang.Thread.run(Thread.java:619) aused by: java.awt.HeadlessException at java.awt.GraphicsEnvironment.checkHGadlGss(GraphicsEnvironment.java:1 at java.awt.Window.init(Window.java:432) at java.awt.Frame.init(Frame.java:403) at javax.swing.JFrame.cinit(3Frame.java:202) at org.mozilla.javascript.tools.debugger.SwingGui.cinit(SwingGui.java:1 I've read about a successful attempt under Windows 7 32-bit So... do you know is it anyhow possible to run tomcat with Swing GUI under Win7 64-bit or is it a system limitation...? It's eaten 2 days and I'm starting to be a little despaired. thx from advance - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 creating Swing GUI under Windows 7 64bit
2011/8/11 Michał Wróbel michal.wro...@evolpe.pl: P.S. I managed to run this Swing window on virtual windows XP machine, so this problem seems to be realted with Win7 64 bit. Any possible causes and workarounds on your minds? You cannot display GUI windows if you are running Tomcat as a service. That is a feature of Windows Vista and later. Use *.bat files, that are available in *.zip distributives. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 creating Swing GUI under Windows 7 64bit
I know, I tried also catalina.bat, just as I've written in previous mail above but to no avail.. W dniu 2011-08-11 18:48, Konstantin Kolinko pisze: 2011/8/11 Michał Wróbelmichal.wro...@evolpe.pl: P.S. I managed to run this Swing window on virtual windows XP machine, so this problem seems to be realted with Win7 64 bit. Any possible causes and workarounds on your minds? You cannot display GUI windows if you are running Tomcat as a service. That is a feature of Windows Vista and later. Use *.bat files, that are available in *.zip distributives. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: -d64 disappears from command line in ps output?
From: Bill Davidson [mailto:bill...@gmail.com] Subject: Re: -d64 disappears from command line in ps output? In what way does this concern Tomcat? I wasn't sure if it had something to do with the way it was launched. Are you using jsvc? If so, it might strip off parameters it doesn't recognize (that's only speculation). Documentation for -d64 with a standard launcher seems to indicate it's only applicable for Solaris 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. Let's look at the rest of the text in that area: Since Solaris has both a 32 and 64-bit J2SE implementation contained within the same installation of Java, you can specify either version. If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment. All other platforms (Windows and Linux) contain separate 32 and 64-bit installation packages. If both packages are installed on a system, you select one or the other by adding the appropriate bin directory to your path. For consistency, the Java implementations on Linux accept the -d64 option. So, again, the -d64 is only effective on Solaris, and is simply ignored on Linux unless you try to use it with a 32-bit JVM. Are you saying that the Linux64-bit Java is 64 bit only and therefore this option is irrelevant? Highly likely. It's possible to install a 32-bit JVM on a 64-bit platform, but I wouldn't think the package managers would do that by default. If that is true, then the Java man page is deficient and confusing. Not the first time. What do you think -d64 does? It runs the program in a 64-bit environment. This is where it gets confusing. A JVM - including the standard launcher - can be built as either 32- or 64-bit, not both, so a given JVM installation is one or the other (except on Solaris). The execution mode you get depends on the JVM you've installed, not on command-line options. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 6.0.20 Cleanup after application crash
I just got the info on mod_jk: sh-3.00# *ls -l mod_jk.so* -rwxrwxr-x 1 root root 1004496 May 8 00:29 mod_jk.so sh-3.00# *cksum mod_jk.so* 2745861777 1004496 mod_jk.so sh-3.00# *strings mod_jk.so |grep mod_jk/* mod_jk/1.2.31 (1026297) mod_jk/1.2.31 mod_jk/1.2.31 (1026297) I have the latest configs, but haven't had time to sanitize them. Will post later tonight. Danté On 08/10/2011 06:23 PM, Mark Eggers wrote: - Original Message - From: Dante Bell dantepasqu...@cocoanet.us To: Tomcat Users List users@tomcat.apache.org Cc: Christopher Schultz ch...@christopherschultz.net Sent: Wednesday, August 10, 2011 11:26 AM Subject: Re: TC 6.0.20 Cleanup after application crash Hi Chris, I did indeed read and digest Mark's email and talked to the vendor about that issue. The stack trace on the old blog post is from the one Mark was helping out with (man, that was a really bad sentance!). This is a different issue :( I don't have a stack trace and I don't have access to the lab they are running these tests in. I've requested the stack traces when this happens, but haven't received those yet. Your question about 'crash' is valid and the explanation I received was that the load test application crashes. That's all I have at this time from them. I'm helping them from a dark, distant planet and only see the things they want me to see ;) Weirdly, it doesn't sound like TC is dead from what they are telling me, after 15 minutes it starts serving up db responses! Yes, they are using mod_jk. On 08/10/2011 12:55 PM, Christopher Schultz wrote: Dante, On 8/10/2011 11:57 AM, Dante Bell wrote: We are seeing that after an application crash (customized load tester with minimal error handling so it crashes often) When you say crash, do you mean you get a stack trace in the logs and Tomcat stays up, or do you mean that you bring-down the JVM? If you bring-down the JVM, what is the error that is occurring (check hs_*.txt files laying around in the working directory for that)? that TC isn't releasing the connection for about 15 minutes. If TC is truly dead, then it's not holding connections at all. That would be the OS holding them. What makes you think they are not being released? What counts as released? I've reviewed some of the worker directives, but I'm really unsure as to which one or combination would shorten this interval significantly. Does that mean you are using mod_jk/mod_proxy_ajp? Good to have that kind of information. The Apache server still serves up static content, which makes me think that there isn't anything at the OS or Apache layer that is causing the connection to hang around (granted, this isn't an absolute and we are investigating these 2 components also). So you're using Apache httpd, too. Also good to know. We've done some minor TCP/IP tuning in the Solaris stack, and that has helped with other issues regarding heavy loads. On Solaris. If TC is the culprit, would we need to be setting the advanced connector directives such as: |recovery_options|4: close the connection to Tomcat, if we detect an error when writing back the answer to the client (browser) That depends upon what the errors actually are. Care to tell us about them? PS. Configs can be found at: http://bit.ly/pFIzO0 Sigh. You should look into template workers. Apache httpd MaxClients setting default is 256. Connector MaxThreads is set to 750, so Tomcat should have almost 3 times more than you need. Where do you see 750 stuck threads? I looked at your thread dump. You clearly have not read Mark's previous response on this list where he told you exactly what was happening: your webapp is killing itself with these SingleThreadModel servlets. This is not thread starvation due to configuration, this is thread starvation due to a poorly-implemented web application. Apache:* Apache HTTP Server Version 2.2 -- prefork with mpm *Tomcat:* 6.0.20 *JK Connector:* Same as whatever is bundled in with Apache 2.2 (from customer) *Solaris* Solaris 10 10/09 s10s_u8wos_08a SPARC Aah, here's all the configuration information. Description then context. Not the best term paper I've ever read. :( I think you mean prefork MPM. Apache httpd does not bundle mod_jk. Check your version. As is my normal self, this will be horrifically long. I apologize for that in advance. Here are the cliff notes first. 1. Clean up your httpd.conf - it's a mess Notes in the main message 2. Clean up your workers.properties - it's not a mess, but certainly missing things Notes and an example in the main message 3. Clean up your AJP Connector in server.xml - it's a mess Notes and an example in the main message 4. Use JMeter - well-tested, robust, freely available testing tool http://jakarta.apache.org/jmeter/ 5. Fix the application - there really is no
Re: AW: AW: Multiple Tomcat Servers connect to IIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander, On 8/11/2011 5:45 AM, Alexander Diedler wrote: Hello, Yes thanks, with adding the vHost Name it works with one exception. I cannot access the Manager App. I get a auth Window, the credentials are correct, but I do not get into the Manager App. Uriworkermap.properties: /manager=worker1 Uh... still missing virtual host? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5EKjsACgkQ9CaO5/Lv0PCG+wCePtyETQsa3W1Y98sw4YMlLZUu YdIAn0onDQHz82Le6iwyxMvYouWC5WJI =XUSF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat war context path
Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat war context path
From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Subject: Tomcat war context path Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war Unlikely; I suspect it's really: http://localhost:8080/abc-SNAPSHOT-01 How can I change the context root such that I can access it as http://localhost:8080/abc? Deploy it as abc.war. Problem is that abc-SNAPSHOT-01.war name could change with the build version change. Which is an issue easily resolved by your deployment script. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Multiple Tomcat Servers connect to IIS
Alexander Diedler wrote: Hello, Yes thanks, with adding the vHost Name it works with one exception. I cannot access the Manager App. I get a auth Window, the credentials are correct, but I do not get into the Manager App. Uriworkermap.properties: /manager=worker1 /manager/*=worker1 /docs=worker1 /*=worker1 /go/*=worker1 /go=worker1 /show/*=worker1 # Mapping all URI which end with a common suffix: #*.jsp=worker1 ##vHosts for Tomcat 7.0.19 /SiteB.xxx.de/*=worker2 /SiteB.xxx.de *=worker2 /SiteB.xxx.de /manager/*=worker2 /SiteB.xxx.de /manager*=worker2 Alexander, as Chris points out succintely, it looks like you are a bit confused and may be confusing isapi_redirector. When you say : /manager/*=worker1 in a virtual host context, that means that isapi_redirector ignores the hostname part, and is sending all requests for /manager/* to worker1. But then later you say /SiteB.xxx.de/manager/*=worker2 which contradicts the above. Also, /SiteB.xxx.de/*=worker2 and /SiteB.xxx.de/manager/*=worker2 overlap. There is no real reason for the second line, after the first. So it's a bit hard to guess what isapi_redirector will do with all these superfluous and contradictory instructions. And even worse, you say /*=worker1 So it means that you are sending everything to worker1, leaving nothing for worker2. One wonders how poor worker2 gets anything to do at all.. Get a cup of coffee, sit down and write down, on paper, - which URLs you do /not/ want to go to Tomcat, but be processed locally by the httpd front-end - for the URLs which /should/ go to Tomcat, which ones should go to tomcat1 and which should go to tomcat2 Then think that when you write /* that also covers /abc, /abcd/, /xyz, /xyz/abc, etc... If everything addressed to siteA should go to the tomcat worker1, and everything addressed to siteB should go to the tomcat worker2, then the following 2 lines in uriworkermap.properties should be enough : /siteA.xxx.de/*=worker1 /siteB.xxx.de/*=worker2 but then one wonders why you even use a front-end httpd. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Parallel Deployment Sessions: What am I Missing?
Following up on my post the other day ... I figured out a clean way to generate a Catalog##~~~.war Grails app that just yields an outage page. Today I deployed tested sessions are not behaving as I expected. Here's what I have 1) Deployed Catalog##0002.war. started. 2) Access app (/Catalog) start a session (confirmed in Tomcat Manager). 3) Deploy Catalog##~~~.war started. 4) Access app again (/Catalog). I immediately get the outage page. 5) Stop Catalog##~~~. 5) Access /Catalog. Session is back. I was expecting to see the original app, not an outage page. I checked in Manager it shows 1 session associated with Catalog##0002 and none with Catalog##~~~, as expected. Am I confused as to what should be happening? -- Jonathan Rosenberg Founder Executive Director Tabby's Place, a Cat Sanctuary http://www.tabbysplace.org/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment Sessions: What am I Missing?
On 11/08/2011 21:56, Jonathan Rosenberg wrote: Following up on my post the other day ... I figured out a clean way to generate a Catalog##~~~.war Grails app that just yields an outage page. Today I deployed tested sessions are not behaving as I expected. Here's what I have 1) Deployed Catalog##0002.war. started. 2) Access app (/Catalog) start a session (confirmed in Tomcat Manager). 3) Deploy Catalog##~~~.war started. 4) Access app again (/Catalog). I immediately get the outage page. 5) Stop Catalog##~~~. 5) Access /Catalog. Session is back. I was expecting to see the original app, not an outage page. I checked in Manager it shows 1 session associated with Catalog##0002 and none with Catalog##~~~, as expected. Am I confused as to what should be happening? Use fiddler, firebug or similar to look at the headers being sent to Tomcat. Check the session IDs match up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Get SSO ID on server
Hi: I've configurated my server.xml with Valve className=org.apache.catalina.authenticator.SingleSignOn/ and I've got deployed two web applications with Realm authentication How I can get SSO ID on a servlet ? I want to know this ID without browser sends a cookie to server. I don't need this SSO ID be equal to JSESSIONIDSSO . I only want to relate two sessions ( with different JSSESSIONID ) with only one identifier There is a session.getId() method, but retrieves session ID for each application. I need something like session.getSSOId() Thanks and regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get SSO ID on server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chema, On 8/11/2011 5:00 PM, Chema wrote: How I can get SSO ID on a servlet? Get the cookie value for JSESSIONIDSSO. I want to know this ID without browser sends a cookie to server. Browser cookies are a requirement to use Tomcat's SSO. Given that, just read the cookie out of the request. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ESiAACgkQ9CaO5/Lv0PCEDgCfXTvEPamY2d5J9qfe8JU2A6Qz MowAoMMjrSySwa2q9KMzD4elibSDxe6b =uBkF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment Sessions: What am I Missing?
Great idea. I just retested aith Firebug the JSESSIONIDs are identical. Ideas, anyone? -- Jonathan Rosenberg Founder Executive Director Tabby's Place, a Cat Sanctuary http://www.tabbysplace.org/ On Thu, Aug 11, 2011 at 5:01 PM, Mark Thomas ma...@apache.org wrote: On 11/08/2011 21:56, Jonathan Rosenberg wrote: Following up on my post the other day ... I figured out a clean way to generate a Catalog##~~~.war Grails app that just yields an outage page. Today I deployed tested sessions are not behaving as I expected. Here's what I have 1) Deployed Catalog##0002.war. started. 2) Access app (/Catalog) start a session (confirmed in Tomcat Manager). 3) Deploy Catalog##~~~.war started. 4) Access app again (/Catalog). I immediately get the outage page. 5) Stop Catalog##~~~. 5) Access /Catalog. Session is back. I was expecting to see the original app, not an outage page. I checked in Manager it shows 1 session associated with Catalog##0002 and none with Catalog##~~~, as expected. Am I confused as to what should be happening? Use fiddler, firebug or similar to look at the headers being sent to Tomcat. Check the session IDs match up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment Sessions: What am I Missing?
BTW: I'm using Apache Tomcat/7.0.6 JDK 1.6.0_22-b04 on Linux. -- Jonathan Rosenberg Founder Executive Director Tabby's Place, a Cat Sanctuary http://www.tabbysplace.org/ On Thu, Aug 11, 2011 at 6:00 PM, Jonathan Rosenberg j...@tabbysplace.org wrote: Great idea. I just retested aith Firebug the JSESSIONIDs are identical. Ideas, anyone? -- Jonathan Rosenberg Founder Executive Director Tabby's Place, a Cat Sanctuary http://www.tabbysplace.org/ On Thu, Aug 11, 2011 at 5:01 PM, Mark Thomas ma...@apache.org wrote: On 11/08/2011 21:56, Jonathan Rosenberg wrote: Following up on my post the other day ... I figured out a clean way to generate a Catalog##~~~.war Grails app that just yields an outage page. Today I deployed tested sessions are not behaving as I expected. Here's what I have 1) Deployed Catalog##0002.war. started. 2) Access app (/Catalog) start a session (confirmed in Tomcat Manager). 3) Deploy Catalog##~~~.war started. 4) Access app again (/Catalog). I immediately get the outage page. 5) Stop Catalog##~~~. 5) Access /Catalog. Session is back. I was expecting to see the original app, not an outage page. I checked in Manager it shows 1 session associated with Catalog##0002 and none with Catalog##~~~, as expected. Am I confused as to what should be happening? Use fiddler, firebug or similar to look at the headers being sent to Tomcat. Check the session IDs match up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Generating SSL certificates
Our certificates are about to expire and I need to generate new ones for tomcat. I'm using keytool, but getting a strange error. [root]# keytool -genkey -alias tomcat -keyalg RSA -keysize 2048 -keystore keystore Enter keystore password: keytool error: java.lang.Exception: Key pair not generated, alias tomcat already exists ok, fair enough, so I try and delete it and I get this: [roots]# keytool -delete -alias tomcat keytool error: java.io.EOFException failing being able to do it in keytool, is it possible to delete the entire keychain and start from scratch? If so how? Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment Sessions: What am I Missing?
Trying to fall asleep and just had a thought on my problem: are context-param values shared across different context versions (as implemented in parallel deployment)? -- JR On Aug 11, 2011 6:10 PM, Jonathan Rosenberg j...@tabbysplace.org wrote: BTW: I'm using Apache Tomcat/7.0.6 JDK 1.6.0_22-b04 on Linux. -- Jonathan Rosenberg Founder Executive Director Tabby's Place, a Cat Sanctuary http://www.tabbysplace.org/ On Thu, Aug 11, 2011 at 6:00 PM, Jonathan Rosenberg j...@tabbysplace.org wrote: Great idea. I just retested aith Firebug the JSESSIONIDs are identical. Ideas, anyone? -- Jonathan Rosenberg Founder Executive Director Tabby's Place, a Cat Sanctuary http://www.tabbysplace.org/ On Thu, Aug 11, 2011 at 5:01 PM, Mark Thomas ma...@apache.org wrote: On 11/08/2011 21:56, Jonathan Rosenberg wrote: Following up on my post the other day ... I figured out a clean way to generate a Catalog##~~~.war Grails app that just yields an outage page. Today I deployed tested sessions are not behaving as I expected. Here's what I have 1) Deployed Catalog##0002.war. started. 2) Access app (/Catalog) start a session (confirmed in Tomcat Manager). 3) Deploy Catalog##~~~.war started. 4) Access app again (/Catalog). I immediately get the outage page. 5) Stop Catalog##~~~. 5) Access /Catalog. Session is back. I was expecting to see the original app, not an outage page. I checked in Manager it shows 1 session associated with Catalog##0002 and none with Catalog##~~~, as expected. Am I confused as to what should be happening? Use fiddler, firebug or similar to look at the headers being sent to Tomcat. Check the session IDs match up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Availability of Tomcat 5.5.34
Hi Jim, Is there any update on release date of 5.5.34? Thanks, -Sachin Jim Jagielski wrote: I am tempted to do a release next week... we seem to have enough to warrant it. On Jul 21, 2011, at 5:57 AM, Sachin Mankapure wrote: Thanks. I wanted to know *when* 5.5.34 will be available. I got the answer. Konstantin Kolinko wrote: 2011/7/20 msachin sachin.mankap...@gmail.com: Where can I get information about availability of Tomcat 5.3.34? Thanks. Here: http://tomcat.apache.org/download-55.cgi http://tomcat.apache.org/whichversion.html If you want o be notified about release you can subscribe to the announce@ mailing list I do not think that it can happen sooner than next release of 6.0. There is not much activity with Tomcat 5.5 development. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Availability-of-Tomcat-5.5.34-tp32098293p32106146.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Availability-of-Tomcat-5.5.34-tp32098293p32247100.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
