An attempt was made to authenticate the locked user "admin"
Greeting! we are getting the following warning message from the log, when the machine on but we are not in the office. what is the meaning of the following message? Is anybody outside trying to login? Jul 26, 2012 10:28:32 PM org.apache.catalina.realm.LockOutRealm authenticate WARNING: An attempt was made to authenticate the locked user "admin" Jul 26, 2012 10:28:32 PM org.apache.catalina.realm.LockOutRealm authenticate WARNING: An attempt was made to authenticate the locked user "admin" Jul 26, 2012 10:28:34 PM org.apache.catalina.realm.LockOutRealm authenticate WARNING: An attempt was made to authenticate the locked user "tomcat" Jul 26, 2012 10:28:34 PM org.apache.catalina.realm.LockOutRealm authenticate WARNING: An attempt was made to authenticate the locked user "tomcat" Jul 26, 2012 10:28:35 PM org.apache.catalina.realm.LockOutRealm authenticate WARNING: An attempt was made to authenticate the locked user "manager" Jul 26, 2012 10:28:36 PM org.apache.catalina.realm.LockOutRealm authenticate WARNING: An attempt was made to authenticate the locked user "manager" Thanks for your help. With Regards, Srinibas.
Check if a file exists before passing to a servlet in TC7
I'm trying to have Tomcat serve up a directory listing if a file listed in the doesn't exist. I have custom files there that will get passed to my servlet if the normal HTML or JSP files don't exist. In Tomcat 6, this seemed to work nicely. I have my files listed in the welcome file list and if they didn't exist, I'd get a directory listing like I wanted. But, in Tomcat 7, as soon as Tomcat sees that I have a custom file in my , it simply hands off the request to my servlet and I get a 404 from my servlet instead of a directory listing from Tomcat's "default" servlet. Is it possible to have Tomcat 7 check for the existence of a file before it passes a request to my servlet? That way I could get the directory listing from the default servlet? I'm just using the built-in Coyote Web server on both TC6 and TC7, so no external web server should be complicating things. Any direction on this would be greatly appreciated. Thanks in advance! -- Warm Regards, Jordan Michaels - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Intermittent mod_proxy_ajp error - APR does not understand this error code: proxy: dialog
On Fri, Jul 27, 2012 at 4:20 AM, Carlucci, Tony wrote: > >-Original Message- > >From: Igor Cicimov [mailto:icici...@gmail.com] > >Sent: Wednesday, July 25, 2012 9:12 PM > >To: Tomcat Users List > >Subject: Re: Intermittent mod_proxy_ajp error - APR does not understand > this > >error code: proxy: dialog > > > >You have max clients on the apache side set to 400 but only 300 threads on > >tomcat side. No wonder you get 500 error... > > Thanks for the suggestion Igor, I increased the tomcat threads to 400 but > that did not resolve the issue. > > Tony > > > > > >On Wed, Jul 25, 2012 at 12:22 AM, Carlucci, Tony >wrote: > > > >> Cross-posting this to the tomcat users list (also posted to users@httpd > >> )... > >> > >> Hello, I've been trying to track down an intermittent problem with a > Java > >> web application that is running on tcServer fronted by Apache HTTP > Server. > >>We get intermittent "Server Unavailable / HTTP 500" errors, and when > we > >> do see them, there is the same set of log statements written to the > Apache > >> HTTP Server error log: > >> > >> [Mon Jul 23 10:03:15 2012] [error] (70014)End of file found: > >> ajp_ilink_receive() can't receive header > >> [Mon Jul 23 10:03:15 2012] [error] ajp_read_header: ajp_ilink_receive > >> failed > >> [Mon Jul 23 10:03:15 2012] [error] (120006)APR does not understand this > >> error code: proxy: dialog to 127.0.0.1:7071 (127.0.0.1) failed > >> > >> We are not seeing any error messages in the tcServer logs. > >> > >> I believe the issue is with the mod_proxy_ajp module but it's been very > >> difficult tracking down what exactly the problem is. What's > interesting > >> is that this Apache / tcServer configuration is used with other > >> applications that work just fine and never have the intermittent 500 > error. > >> We also can run our application strictly in Tomcat (no Apache front) > >> without any intermittent errors. > >> > >> We haven't ruled out that there could be something in our Java > application > >> code that is causing this, in combination with the mod_proxy_ajp module, > >> but we have hit a wall as to what this issue could be. Has anyone else > >> experienced a similar intermittent issue combined with the above error > >> messages? Below is a copy of the error log and some configuration > settings. > >> > >> Thanks, Tony > >> > >> - > >> Apache HTTP Error Log > >> - > >> [Mon Jul 23 10:03:15 2012] [debug] mod_cache.c(141): Adding CACHE_SAVE > >> filter for /myapp/ > >> [Mon Jul 23 10:03:15 2012] [debug] mod_cache.c(148): Adding > >> CACHE_REMOVE_URL filter for /myapp/ > >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy_ajp.c(45): proxy: AJP: > >> canonicalising URL //127.0.0.1:7071/myapp/ > >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(1506): [client > >> ***cleansed***] proxy: ajp: found worker ajp://127.0.0.1:7071/myapp for > >> ajp://127.0.0.1:7071/myapp/ > >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy.c(1020): Running scheme ajp > >> handler (attempt 0) > >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy_http.c(1963): proxy: HTTP: > >> declining URL ajp://127.0.0.1:7071/myapp/ > >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy_ajp.c(681): proxy: AJP: > >> serving URL ajp://127.0.0.1:7071/myapp/ > >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(2011): proxy: AJP: has > >> acquired connection for (127.0.0.1) > >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(2067): proxy: connecting > >> ajp://127.0.0.1:7071/myapp/ to 127.0.0.1:7071 > >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(2193): proxy: connected > >> /myapp/ to 127.0.0.1:7071 > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(224): Into > >> ajp_marshal_into_msgb > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[0] [x-forwarded-for] = [***cleansed***] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[1] [Host] = [***cleansed***] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[2] [Connection] = [keep-alive] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[3] [User-Agent] = [Mozilla/5.0 (Windows NT > >> 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 > >> Safari/536.11] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[4] [Accept] = > >> [text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[5] [Accept-Encoding] = [gzip,deflate,sdch] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[6] [Accept-Language] = [en-US,en;q=0.8] > >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): > >> ajp_marshal_into_msgb: Header[7] [Accept-Charset] = > >> [ISO-8859-1,utf-8;q=0.7,*;q=0.3] > >> [Mon Jul 23 10:03:15 2012] [debug] a
RE: Calling Bootstrap.main from a Java program
Thanks, for this information. It helped me with everything I needed to know,
including things I didn't realize that I needed to know at the time.
Mike
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Sunday, July 15, 2012 4:55 PM
To: Tomcat Users List
Subject: RE: Calling Bootstrap.main from a Java program
> From: Mike O'Leary [mailto:tmole...@uw.edu]
> Subject: Calling Bootstrap.main from a Java program
> When I tried this running my Java program in Eclipse, the call to
> Bootstrap.main(new String[]{"start"}) did not return.
The thread that calls Bootstrap.main() ends up waiting for input on the
shutdown port - which a thread dump would easily show you.
> running startup.bat in a command prompt window gets Tomcat running and
> then returns to a command prompt.
You appear to have missed that startup.bat kicks off catalina.bat in a separate
process.
> Is there a way to call Bootstrap.main(new String[]{"start"}) in an
> application's main thread so that it returns and Tomcat continues
> running?
You shouldn't really be doing it that way, but disabling the shutdown port in
your server.xml might work.
> What is the best way to start and stop Tomcat programmatically from a
> Java application? If it is better to do it using a different class,
> such as Tomcat or Embedded, could someone point me to information
> about how to do that?
Use the Tomcat class; Embedded is deprecated. Read the Javadoc for
org.apache.catalina.startup.Tomcat. You could also try launching Tomcat in a
separate process, rather than inside the JVM you're already using.
> I tried using the Tomcat class recently and I couldn't get it to work
> either.
Can't provide help without specifics.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Happy Birthday, Chuck!
Chuck, ich danke dir für deineehrliche bemühungen und wünsche alles gute zum Geburtstag. Und hoffe du bist immerin dieser liste. Wilhelm El 26/07/2012 03:46 p.m., Rainer Jung escribió: On 26.07.2012 15:46, Gregor S. wrote: Hi Chuck, thanks again for your valuable comments on this list, and keep it up! Cheers! +2 ! Rainer - 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: Happy Birthday, Chuck!
On 26.07.2012 15:46, Gregor S. wrote: Hi Chuck, thanks again for your valuable comments on this list, and keep it up! Cheers! +2 ! Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: issue with iis 7.5 ajpconnector
[snip] > > Without rubbing it in too forcefully, this is exactly the reason why it is > important to provide precise technical details right from the start. Lack of details yep, my fault. You write thing presuming people who deal with it every day know and think the same way. Always better for more info > The people on this list are trying to be helpful, and they do this for fun. And greatly appreciated > At the same time, it is a bit frustrating spending time to exchange multiple > messages back and forth, to end up realising that we may be talking about > some unknown or broken or unsupported piece of software (or hardware, as > the case may be). True > It just wastes time for everyone, and also delays the eventual resolution of > your problem. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.25 on an AS/400, V5R4, Another try. Help?
Tim Watts wrote:
import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
public class FindClass {
public static void main(String[] args) {
try {
URLClassLoader loader = new URLClassLoader(
new URL[] {new
File("/wintouch/tomcat/lib/catalina.jar").toURI().toURL()});
loader.loadClass(args[0]);
System.out.println("URLClassLoader found class '" +args[0]
+"'");
}
catch (Exception e) {
e.printStackTrace();
}
}
}
I tried it. I'm surprised I was able to get it to compile and run on
only the second try (the first try, I had left the stream file editor in
the default EBCDIC codepage when I pasted in your source, which JAVAC,
not surprisingly, didn't like at all).
At any rate, I get:
java FindClass org.apache.catalina.startup.Catalina
URLClassLoader found class 'org.apache.catalina.startup.Catalina'
And so far as I can determine without doing a clean install of Tomcat,
nothing is customized at all, at this point, other than maybe setting
port numbers (which it isn't even getting to, yet), and adding your
diagnostic lines in logging.properties.
Paul Holm, on the Midrange.com Java list, suggested turning on verbose
mode on Java; I'm not entirely sure how I would even do that for Tomcat.
What would be the next step?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Permanent servlet in TC7
Hi Chris, Thanks for the response. Sorry, where I said "...unload a server any time" I should have said 'servlet'. I have read that Tomcat does not unload servlets (even though it would be permissible to do so), but as you say, I have done some logging in the destroy method, and I see this behavior. Here's the scenario: I have 3 webapps, let's call them A, B, C. They are all hosted in the same TC7 instance currently, but they could also all be hosted on different machines in different TC7 containers. A certain servlet within app B & C (let's call them B1 and C1) upon init make a call to a servlet in app A (let's call it A1). What I see is A1, B1, and C1 all initialize. The init is done by a thread called " pool-2-thread-1", which seems like a system thread. Ok no problem. Then, for some reason, A1's destroy method is called, and it is called by a thread named " http-apr-8080-exec-3", making me think it is being called by a thread processing the request for either B1 or C1, since no other requests from anyone outside of B or C have happened yet. After destroy winds down, then, A1's init method is called by a thread named " http-apr-8080-exec-11" - another request processing thread I assume. Everything all works out in the end, and after that I don't see A1, B1, or C1 ever destroyed - but am I guaranteed that they won't ever be destroyed again unless TC is shutdown or they are manually unloaded? I understand that given servlets can by spec go up & down, maybe using them was not the right choice for an application that needs permanency, but we're too late in development to make that switch now. So I'm looking for a guarantee that no automatic destroys will happen going forward just because Tomcat decides to do it on its own. If it is instructed to shutdown/undeploy/unload by some outside system or by a human user, that's fine, I'm not worried about that. But I don't want these servlets to be destroyed just because Tomcat decides to do so for whatever reason. Hope that helps clarify, and thanks for the feedback. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, July 26, 2012 12:38 PM To: Tomcat Users List Subject: Re: Permanent servlet in TC7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chip, On 7/26/12 3:19 PM, Chip McVey wrote: > In TC7, is there a way to tell Tomcat to never unload a given servlet > unless Tomcat itself is being shutdown? I want a single servlet > instance that I can know will exist for the life of the tomcat process > without being unloaded & reloaded (unless someone manually instructs > Tomcat to do so, of course). > > Yes, I know I'm "not supposed to do this" and that the servlet spec > says a container is allowed to unload a server any time as long as a > request is not in process. I still would like to know if there's some > Tomcat specific way to tell TC7 to never unload the servlet. And yes, > I realize even if there is such a way that future versions of Tomcat > may remove this capability. :) You have said both "servlet" and "server": which did you mean? Do you need a particular web application to stay loaded? That's easy: simply don't undeploy it. Do you need a single (or multiple) servlet(s) to stay loaded all the time? That's also easy: I don't believe Tomcat ever actually unloads a servlet. (You can easily test this by implementing the destroy() method and emitting some kind of log). What is it about the servlet that it needs to stay loaded? Servlets aren't really supposed to have any state, so unloading and re-loading the servlet shouldn't represent anything traumatic to your web application. If you have to have some kind of data loaded all the time, consider moving that data into the ServletContext (aka "application") attributes: then the servlet can be unloaded and re-loaded at will and the data will persist. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlARnJ8ACgkQ9CaO5/Lv0PCaGQCgv7Kgkl04ElbBu5bkqNtuuX+v 5OsAn1MSf6i3CH9vIogXTb+aUKRYq0WN =6vQK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Permanent servlet in TC7
On 26/07/2012 22:38, Christopher Schultz wrote: > Chip, > > On 7/26/12 3:19 PM, Chip McVey wrote: >> In TC7, is there a way to tell Tomcat to never unload a given >> servlet unless Tomcat itself is being shutdown? I want a single >> servlet instance that I can know will exist for the life of the >> tomcat process without being unloaded & reloaded (unless someone >> manually instructs Tomcat to do so, of course). > >> Yes, I know I'm "not supposed to do this" and that the servlet >> spec says a container is allowed to unload a server any time as >> long as a request is not in process. I still would like to know if >> there's some Tomcat specific way to tell TC7 to never unload the >> servlet. And yes, I realize even if there is such a way that future >> versions of Tomcat may remove this capability. :) > > You have said both "servlet" and "server": which did you mean? > > Do you need a particular web application to stay loaded? That's easy: > simply don't undeploy it. > > Do you need a single (or multiple) servlet(s) to stay loaded all the > time? That's also easy: I don't believe Tomcat ever actually unloads a > servlet. (You can easily test this by implementing the destroy() > method and emitting some kind of log). > > What is it about the servlet that it needs to stay loaded? Servlets > aren't really supposed to have any state, so unloading and re-loading > the servlet shouldn't represent anything traumatic to your web > application. > > If you have to have some kind of data loaded all the time, consider > moving that data into the ServletContext (aka "application") > attributes: then the servlet can be unloaded and re-loaded at will and > the data will persist. +1 -> ServletContextListener p > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Permanent servlet in TC7
- Original Message - > Hi, > > In TC7, is there a way to tell Tomcat to never unload a given servlet > unless Tomcat itself is being shutdown? I want a single servlet > instance that I can know will exist for the life of the tomcat > process without being unloaded & reloaded (unless someone manually > instructs Tomcat to do so, of course). I'm not sure this will do exactly what you want, but if you set "autoDeploy" on the Host tag to "false" it will prevent any applications from deploying / undeploying while Tomcat is running. This would roughly tell Tomcat to start an app (and it's servlets) when Tomcat starts up and shut down an app (and it's servlets) when Tomcat is shutdown. I say roughly because I believe there might be a few ways to work around that (manager, jmx). > Yes, I know I'm "not supposed to do this" and that the servlet spec > says a container is allowed to unload a server any time as long as a > request is not in process. I still would like to know if there's > some Tomcat specific way to tell TC7 to never unload the servlet. > And yes, I realize even if there is such a way that future versions > of Tomcat may remove this capability. :) Maybe you could take a step back and tell us about your general use case for this feature. With that in mind, perhaps someone can suggest a solution to the general problem even if your specific request is not possible. Dan > Thanks in advance, > > Chip > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Permanent servlet in TC7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chip, On 7/26/12 3:19 PM, Chip McVey wrote: > In TC7, is there a way to tell Tomcat to never unload a given > servlet unless Tomcat itself is being shutdown? I want a single > servlet instance that I can know will exist for the life of the > tomcat process without being unloaded & reloaded (unless someone > manually instructs Tomcat to do so, of course). > > Yes, I know I'm "not supposed to do this" and that the servlet > spec says a container is allowed to unload a server any time as > long as a request is not in process. I still would like to know if > there's some Tomcat specific way to tell TC7 to never unload the > servlet. And yes, I realize even if there is such a way that future > versions of Tomcat may remove this capability. :) You have said both "servlet" and "server": which did you mean? Do you need a particular web application to stay loaded? That's easy: simply don't undeploy it. Do you need a single (or multiple) servlet(s) to stay loaded all the time? That's also easy: I don't believe Tomcat ever actually unloads a servlet. (You can easily test this by implementing the destroy() method and emitting some kind of log). What is it about the servlet that it needs to stay loaded? Servlets aren't really supposed to have any state, so unloading and re-loading the servlet shouldn't represent anything traumatic to your web application. If you have to have some kind of data loaded all the time, consider moving that data into the ServletContext (aka "application") attributes: then the servlet can be unloaded and re-loaded at will and the data will persist. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlARnJ8ACgkQ9CaO5/Lv0PCaGQCgv7Kgkl04ElbBu5bkqNtuuX+v 5OsAn1MSf6i3CH9vIogXTb+aUKRYq0WN =6vQK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Permanent servlet in TC7
2012/7/26 Chip McVey : > Hi, > > > > In TC7, is there a way to tell Tomcat to never unload a given servlet unless > Tomcat itself is being shutdown? I want a single servlet instance that I can > know will exist for the life of the tomcat process without being unloaded & > reloaded (unless someone manually instructs Tomcat to do so, of course). I know that this is not a valid answer, but I would like to know why you'd like to do something like that - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Permanent servlet in TC7
Hi, In TC7, is there a way to tell Tomcat to never unload a given servlet unless Tomcat itself is being shutdown? I want a single servlet instance that I can know will exist for the life of the tomcat process without being unloaded & reloaded (unless someone manually instructs Tomcat to do so, of course). Yes, I know I'm "not supposed to do this" and that the servlet spec says a container is allowed to unload a server any time as long as a request is not in process. I still would like to know if there's some Tomcat specific way to tell TC7 to never unload the servlet. And yes, I realize even if there is such a way that future versions of Tomcat may remove this capability. :) Thanks in advance, Chip
Re: Tomcat 7.0.25 on an AS/400, V5R4, Another try. Help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James, On 7/26/12 11:57 AM, James Lampert wrote: > Tim Watts wrote: > >> http://tomcat.10.n6.nabble.com/Tomcat-7-0-25-on-an-AS-400-V5R4-Another-try-Help-td4984199.html#a4984215 >> > >> >>> - Add these lines to the end of conf/logging.properties: >>> >>> org.apache.catalina.startup.Bootstrap.level = ALL >>> org.apache.catalina.startup.ClassLoaderFactory.level = ALL > > No effect whatsoever. The catalina.out log and the spool file > produced by STDOUT are exactly the same as before. Maybe it's time to start thinking stupidly yet practically: run a guest virtualized OS that will be a bit more friendly to you ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlARkhMACgkQ9CaO5/Lv0PCBZQCgwQWHY1DCMRAfOUaIqk1EH8gH GJwAn3RveOXLk/PP9lZNfhqb6rzmXu6P =WBXN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Intermittent mod_proxy_ajp error - APR does not understand this error code: proxy: dialog
>-Original Message- >From: Igor Cicimov [mailto:icici...@gmail.com] >Sent: Wednesday, July 25, 2012 9:12 PM >To: Tomcat Users List >Subject: Re: Intermittent mod_proxy_ajp error - APR does not understand this >error code: proxy: dialog > >You have max clients on the apache side set to 400 but only 300 threads on >tomcat side. No wonder you get 500 error... Thanks for the suggestion Igor, I increased the tomcat threads to 400 but that did not resolve the issue. Tony > >On Wed, Jul 25, 2012 at 12:22 AM, Carlucci, Tony wrote: > >> Cross-posting this to the tomcat users list (also posted to users@httpd >> )... >> >> Hello, I've been trying to track down an intermittent problem with a Java >> web application that is running on tcServer fronted by Apache HTTP Server. >>We get intermittent "Server Unavailable / HTTP 500" errors, and when we >> do see them, there is the same set of log statements written to the Apache >> HTTP Server error log: >> >> [Mon Jul 23 10:03:15 2012] [error] (70014)End of file found: >> ajp_ilink_receive() can't receive header >> [Mon Jul 23 10:03:15 2012] [error] ajp_read_header: ajp_ilink_receive >> failed >> [Mon Jul 23 10:03:15 2012] [error] (120006)APR does not understand this >> error code: proxy: dialog to 127.0.0.1:7071 (127.0.0.1) failed >> >> We are not seeing any error messages in the tcServer logs. >> >> I believe the issue is with the mod_proxy_ajp module but it's been very >> difficult tracking down what exactly the problem is. What's interesting >> is that this Apache / tcServer configuration is used with other >> applications that work just fine and never have the intermittent 500 error. >> We also can run our application strictly in Tomcat (no Apache front) >> without any intermittent errors. >> >> We haven't ruled out that there could be something in our Java application >> code that is causing this, in combination with the mod_proxy_ajp module, >> but we have hit a wall as to what this issue could be. Has anyone else >> experienced a similar intermittent issue combined with the above error >> messages? Below is a copy of the error log and some configuration settings. >> >> Thanks, Tony >> >> - >> Apache HTTP Error Log >> - >> [Mon Jul 23 10:03:15 2012] [debug] mod_cache.c(141): Adding CACHE_SAVE >> filter for /myapp/ >> [Mon Jul 23 10:03:15 2012] [debug] mod_cache.c(148): Adding >> CACHE_REMOVE_URL filter for /myapp/ >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy_ajp.c(45): proxy: AJP: >> canonicalising URL //127.0.0.1:7071/myapp/ >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(1506): [client >> ***cleansed***] proxy: ajp: found worker ajp://127.0.0.1:7071/myapp for >> ajp://127.0.0.1:7071/myapp/ >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy.c(1020): Running scheme ajp >> handler (attempt 0) >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy_http.c(1963): proxy: HTTP: >> declining URL ajp://127.0.0.1:7071/myapp/ >> [Mon Jul 23 10:03:15 2012] [debug] mod_proxy_ajp.c(681): proxy: AJP: >> serving URL ajp://127.0.0.1:7071/myapp/ >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(2011): proxy: AJP: has >> acquired connection for (127.0.0.1) >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(2067): proxy: connecting >> ajp://127.0.0.1:7071/myapp/ to 127.0.0.1:7071 >> [Mon Jul 23 10:03:15 2012] [debug] proxy_util.c(2193): proxy: connected >> /myapp/ to 127.0.0.1:7071 >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(224): Into >> ajp_marshal_into_msgb >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[0] [x-forwarded-for] = [***cleansed***] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[1] [Host] = [***cleansed***] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[2] [Connection] = [keep-alive] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[3] [User-Agent] = [Mozilla/5.0 (Windows NT >> 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 >> Safari/536.11] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[4] [Accept] = >> [text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[5] [Accept-Encoding] = [gzip,deflate,sdch] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[6] [Accept-Language] = [en-US,en;q=0.8] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[7] [Accept-Charset] = >> [ISO-8859-1,utf-8;q=0.7,*;q=0.3] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[8] [Cookie] = [SSOTOKEN=***cleansed***] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290): >> ajp_marshal_into_msgb: Header[9] [SSO_LOGIN] = [***cleansed***] >> [Mon Jul 23 10:03:15 2012] [debug] ajp_header.c(290)
Re: Happy Birthday, Chuck!
> > From: Jordan Michaels >To: Tomcat Users List >Sent: Thursday, July 26, 2012 10:38 AM >Subject: Re: Happy Birthday, Chuck! > >Happy birthday. =) > >Warm Regards, >Jordan Michaels > >On 07/26/2012 07:05 AM, Caldarale, Charles R wrote: >>> From: Gregor S. [mailto:rc4...@googlemail.com] >>> Subject: Happy Birthday, Chuck! >> >>> thanks again for your valuable comments on this list, and keep it up! >> >> You're welcome, and thank you. >> >> - Chuck Happy birthday, Chuck. Thanks for the comments and encouragement. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Happy Birthday, Chuck!
Happy birthday. =) Warm Regards, Jordan Michaels On 07/26/2012 07:05 AM, Caldarale, Charles R wrote: From: Gregor S. [mailto:rc4...@googlemail.com] Subject: Happy Birthday, Chuck! thanks again for your valuable comments on this list, and keep it up! You're welcome, and thank you. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.25 on an AS/400, V5R4, Another try. Help?
On Thu, 2012-07-26 at 08:57 -0700, James Lampert wrote: > Tim Watts wrote: > > > http://tomcat.10.n6.nabble.com/Tomcat-7-0-25-on-an-AS-400-V5R4-Another-try-Help-td4984199.html#a4984215 > > >> - Add these lines to the end of conf/logging.properties: > >> > >> org.apache.catalina.startup.Bootstrap.level = ALL > >> org.apache.catalina.startup.ClassLoaderFactory.level = ALL > > No effect whatsoever. The catalina.out log and the spool file produced > by STDOUT are exactly the same as before. > Well, hopefully not EXACTLY the same -- different timestamps right? Right? :-) Looks like it may be using a customized logging configuration. Find that and update the above according to the config file location and/or the logging framework in use. (Sorry, can't be more specific; you're leaving us in the dark as to your set up.) Look in bin/setenv.sh if you have one. Or if you've modified any of the distribution scripts (which generally you shouldn't do) then do a diff against the distribution versions for 7.0.25. Please post these so we're not flying so blind. Also, could this be another ASCII/EBCDIC issue? I seem to recall that was a possibility a long time ago but don't recall if that ever panned out. > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > signature.asc Description: This is a digitally signed message part
Re: Tomcat 7.0.25 on an AS/400, V5R4, Another try. Help?
Tim Watts wrote: http://tomcat.10.n6.nabble.com/Tomcat-7-0-25-on-an-AS-400-V5R4-Another-try-Help-td4984199.html#a4984215 - Add these lines to the end of conf/logging.properties: org.apache.catalina.startup.Bootstrap.level = ALL org.apache.catalina.startup.ClassLoaderFactory.level = ALL No effect whatsoever. The catalina.out log and the spool file produced by STDOUT are exactly the same as before. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat maven plugin + [default] overlay
Hello,
I am having a situation where i couldnt tomcat7:run with overlay in eclipse.
In the eclipse indigo, i am using the maven plugin, and have imported
two maven modules,
the childwebapp which depends on the parentwebapp, which is just like
a skeleton, with it's own classes, jsps, static resources, but also a
runnable webapp of itself.
Doing tomcat7:run on the parentwebapp works well as expected ..
Here's the dependency in the childwebapp's pom, and i dont have any
specific overlay configuration :
group.id
parentwebapp
${project.version}
war
runtime
When i try running tomcat7:run on the childwebapp, i get this error message,
as if it tries to find the war of parentwebapp and try to extract it.
But in my situation, i dont have the war in my development,
since the eclipse maven plugin already resolves the workspace dependencies.
I would imagine using the classes from the workspace instead of
extracting the non-existent war file and load them into the
childwebapp would solve the issue ..
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources)
@ childwebapp ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
childwebapp ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] <<< tomcat7-maven-plugin:2.0-SNAPSHOT:run (default-cli) @ childwebapp <<<
[INFO]
[INFO] --- tomcat7-maven-plugin:2.0-SNAPSHOT:run (default-cli) @ childwebapp ---
[INFO] Running war on http://localhost:8080/childwebapp
[INFO] Creating Tomcat server configuration at
C:\Users\albert\git\Startup\MavenParent\childwebapp\target\tomcat
[INFO] create webapp with contextPath: /childwebapp
[ERROR] fail to extract war file
C:\Users\albert\git\Startup\MavenParent\parentwebapp\target\classes,
reason:The source must not be a di
rectory.
org.codehaus.plexus.archiver.ArchiverException: The source must not be
a directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118)
at
org.apache.tomcat.maven.common.run.DefaultClassLoaderEntriesCalculator.calculateClassPathEntries(DefaultClassLoaderEntriesCalc
ulator.java:149)
at
org.apache.tomcat.maven.plugin.tomcat7.run.RunMojo.createWebappLoader(RunMojo.java:254)
at
org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.createContext(AbstractRunMojo.java:563)
at
org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:927)
at
org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:476)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
What can i do to resolve this situation ?
Thank you,
Albert
--
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.25 on an AS/400, V5R4, Another try. Help?
Tim Watts wrote: I made some suggestions to this effect the other day: http://tomcat.10.n6.nabble.com/Tomcat-7-0-25-on-an-AS-400-V5R4-Another-try-Help-td4984199.html#a4984215 Maybe you already tried them or didn't get the email. Thanks for the link. I'm guessing that the email probably got lost in the perpetual torrential flood of email, because I'm sure it must have arrived, but I never saw it. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Happy Birthday, Chuck!
> From: Gregor S. [mailto:rc4...@googlemail.com] > Subject: Happy Birthday, Chuck! > thanks again for your valuable comments on this list, and keep it up! You're welcome, and thank you. - Chuck
Happy Birthday, Chuck!
Hi Chuck, thanks again for your valuable comments on this list, and keep it up! Cheers! Gregor -- just because you're paranoid, don't mean they're not after you... gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD skype:rc46fi gplus.to/gregor twitter.com/#/2smart4u - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: issue with iis 7.5 ajpconnector
Rainer Jung wrote: On 25.07.2012 22:40, Alex Samad - Yieldbroker wrote: Oh so your saying there was an issue that has been fixed since then .. Okay I get the drill. I had just presumed that there had been no changes since then on the mutex code that ... Any way ... Back once I run up a test box... with the latest release version I'm not pretending that your problems will be fixed by a newer version but analyzing a problem on the basis of a non-released (broken) version seems inefficient. Thanks for updating. Without rubbing it in too forcefully, this is exactly the reason why it is important to provide precise technical details right from the start. The people on this list are trying to be helpful, and they do this for fun. At the same time, it is a bit frustrating spending time to exchange multiple messages back and forth, to end up realising that we may be talking about some unknown or broken or unsupported piece of software (or hardware, as the case may be). It just wastes time for everyone, and also delays the eventual resolution of your problem. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
