Re: Extra Threads in background
Well removing the extra element from my server.xml fixed the problem and I now only have the one Background thread I intended. You are right, less resources consumed. I am not sure where I got the idea I needed: Probably read it as an example in a book. Christopher Schultz wrote: Yup: you have two elements pointing to the same deployment directory. All of your webapps are being deployed one for each . Thus, you get two of them. It is. If your thread has a "please die" boolean that it checks, you should simply set that and allow the thread to finish on its own. This is what I do and it works fine now. The thread dies very fast. -d - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Extra Threads in background
This may be the key to duplicate Thread. I am not really confident in my server.xml so here it is. Note that I have two "hosts" one for "localhost" and the other for the domain "southchurch.atx.cx" Is that correct? Could that cause the application to run twice? Server.xml SSLEngine="on" /> className="org.apache.catalina.mbeans.ServerLifecycleListener" /> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> -- end server.xml I am more confident in the context.xml Begin context.xml --- End context.xml As far as your having two instances of your extra thread running, your webapp might be getting deployed twice. Poorly constructed server.xml and context.xml configs can easily cause this. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Extra Threads in background
Chris, This is a good point. What I am discovering is that while I was calling a terminate method on the Thread in the ContextListener.contextDestroyed() method, my thread lives for quite while, because it is sleeping and does not wake up to test the terminate flag for several minutes. My solution was to reduce the sleep time down to a few seconds and only really do something every 20 time it wakes up. This allowed it to discover the terminate flag much sooner. I did not call the "destroy()" method because I though it was deprecated and dangerous. I noticed that the Probe application does have a destroy Thread which works, but warns of being dangerous. I am still trying to figure out why a second thread is spawned. Haven't gotten to bottom of that issue yet. -d Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 4/28/2009 10:52 PM, David.Meldrum wrote: I need a background task which I implemented as a thread that I stated in the ContextListerner. [snip] The problem I noticed is that while I only call the BackGroundThread.*start()* method once. I see at least two threads running in Tomcat (las seen in Thread dump and looking at it in "Probe"). Are you re-deploying your application at all? If you are only starting your thread, you will be starting a new thread for each deployment. So, if you re-start your application, a second (or third, or fourth) will be created. Tomcat doesn't kill your application's threads when the app dies. You need to end them yourself. Since you already have a ContextListener, just add a destroy() method that shuts down the background thread. Apologies if you're already doing this, but you didn't mention it and I figure it's the most likely scenario. - -chris
Re: Extra Threads in background
Pid, Logging the stack trace is an excellent idea! I already have been counting the the number of Thread starts() (run()) and I found it is indeed being started again somewhere. Looks like I need lots of experiments. My least favorite activity is programming by experiment. -d Pid wrote: David.Meldrum wrote: Running Tomcat 6.0.18 Standalone on Windows XP. I need a background task which I implemented as a thread that I stated in the ContextListerner. In the contextInitilized() method I create and started the background process. I give it a name and made it a daemon. All that works great! The problem I noticed is that while I only call the BackGroundThread.*start()* method once. I see at least two threads running in Tomcat (las seen in Thread dump and looking at it in "Probe"). I only instantiate one instance, but Tomcat behaves like it is also calling start() again after I return out of the Why not override the start method of your thread and drop a stack trace and log message each time it's called? E.g. some.log(Thread.currentThread().getName() + " in " + servletContext.getContextPath() + " Stacktrace:"); new Throwable().printStackTrace(); You might even throw in an AtomicInteger count to see if how many attempts to start are occuring. p ServerContextListener.contextInitialized() method. Now I can program my background task to be thread safe and avoid conflicts with it's clones, but it seems wasteful, and it causes a lot of lock friction. So my question is, why do I see two threads running, when I only started one and how can I avoid the duplicate thread? Before you say why don't you run the task as a separate OS task, I am managing a resource (RS232 serial line) that is owned and controlled by my Tomcat application, so it must run inside Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Extra Threads in background
Running Tomcat 6.0.18 Standalone on Windows XP. I need a background task which I implemented as a thread that I stated in the ContextListerner. In the contextInitilized() method I create and started the background process. I give it a name and made it a daemon. All that works great! The problem I noticed is that while I only call the BackGroundThread.*start()* method once. I see at least two threads running in Tomcat (las seen in Thread dump and looking at it in "Probe"). I only instantiate one instance, but Tomcat behaves like it is also calling start() again after I return out of the ServerContextListener.contextInitialized() method. Now I can program my background task to be thread safe and avoid conflicts with it's clones, but it seems wasteful, and it causes a lot of lock friction. So my question is, why do I see two threads running, when I only started one and how can I avoid the duplicate thread? Before you say why don't you run the task as a separate OS task, I am managing a resource (RS232 serial line) that is owned and controlled by my Tomcat application, so it must run inside Tomcat.
Re: Path problem
OK, I agree about writing, but what about reading? I guess I didn't
realize there was a method called getResourcesStream(), on
ServletContext, so that clears up some confusion. Yet when I read the
javadoc on ServletContext.getRessourceAsStream()
see:
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletContext.html#getResourceAsStream(java.lang.String)
<http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletContext.html#getResourceAsStream%28java.lang.String%29>
It still isn't clear how to properly use this. For example, how do I
get a reference to the "/webapps/MyWebApp/WEB-INF/foo.properties" file?
Like this?
ServletContext.getRessourceAsStream("/webapps/MyWebApp/WEB-INF/foo.properties");?
The javadoc says the argument is a path, but I don't know the full path,
only relative to Tomcat, and I don't really know where Tomcat is.
Also how do I create a file under "/logs"?
Is there some way to determine the path to the /logs directory in a
format that I can create a file under the logs
directory, without assuming where Tomcat is deployed?
-d
Caldarale, Charles R wrote:
From: David.Meldrum [mailto:david.meld...@verizon.net]
Subject: Re: Path problem
actually in my case I am trying to read/write from a
ContextListenr
It's generally a bad idea to ever *write* into the webapp deployment space. You have
no guarantee that the space is writable, nor that the container will provide any
write access. You're much better off writing to files outside of Tomcat's directory
structure, where the path can be provided by system property, environment variable,
, or whatever.
As recommended below, you could use
Class.getResourcesStream(), but as I understand it,
that will give the location of this class under
WEB-INF.
Or anywhere else in the webapp's structure; it's not confined to WEB-INF.
public void contextInitialized(ServletContextEvent event) {
ServletContext sctx = event.getServletContext();
String propPath = sctx.getRealPath(
"/WEB-INF/resource.properties");
FileInputStream inStrm = new FileInputStream(propPath);
.
}
Using ServletContext.getRealPath() is risky; the container is under no
obligation to provide access to the underlying file system (think deployment
via .war file). Much safer and better to use getResourceAsStream().
- 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: Path problem
I still have questions about the path to a file. {This is within a
servlet... actually in my case I am trying to read/write from a
ContextListenr} I understand that just opening a FIle will be relative
to where Tomcat was started. Is there a simple java method (and on what
class) that will give me the correct path to 'webapps/MyApplication/'.
As recommended below, you could use Class.getResourcesStream(), but as
I understand it, that will give the location of this class under
WEB-INF. And that assumes you are calling it from one of your own
classes and the loader picked up your class.
I got the following technique from a book, but I am not in love with it:
public void contextInitialized(ServletContextEvent event) {
ServletContext sctx = event.getServletContext();
String propPath = sctx.getRealPath( "/WEB-INF/resource.properties");
FileInputStream inStrm = new FileInputStream(propPath);
.
}
Is this the proper way to do it?
-d
Caldarale, Charles R wrote:
From: popprem [mailto:popp...@gmail.com]
Subject: Path problem
David answered the critical part of your question, but I thought I'd take a
crack at the rest.
That means tomcat defaultly points to bin directory
"Tomcat" doesn't defaultly [sic] point to anything. The current directory of
the process you used to start Tomcat when using the script happened to be Tomcat's bin
directory - but that's just the way you're using the script, not a Tomcat requirement.
When i used tomcat.exe & installed tomcat in my machine & run
the program,i found that the test file i created in my code
level was in windows/system32/ directory.
Because that's the default current directory for services.
It's almost always a bad idea to depend on the current directory setting in a
complex server environment; if you must have a file system path to something,
better to use one based off a system property. In your case, the
getResourceAsStream() method is much preferred, since it elinates any file
system dependencies.
- 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
Jar wars - Conflicting classes
Windows XP SP 3 Tomcat 6.0.1 JVM 1.6.0 Must all conflicting classes be sorted out on one instance of Tomcat? I have learned not to put application jars (classes) in the jre lib, since they then become common to all applications and if there is a duplicate, but not exact duplicate, then things crash. What I am wondering is, are all the classes loaded into the _same_ JVM? Here is the problem I ran into. Application #1 uses some Quartz scheduling classes. Application #2 also uses Quartz, but apparently a different version. Can these applications live on the same Tomcat instance? In other words if each of the applications has it's own lib, can the classes overlap? I get the feeling the applications will have to be sorted out to use the same Quart library. I read the documentation regarding Class Loader and understand the order in which libraries are searched, but do the classes end up in one single aggregated JVM memory? - Dave
Is this list archived?
Is there a searchable archive of this mailing list? I have a few questions that I am sure have already been answered in the past. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Mapping behind a router
As Gilda Radner would say NEVER MIND! I had some absolute paths in my hrefs instead of relative paths. Shame on me! -d David.Meldrum wrote: I am deploying my tomcat server behind a router. I have the router port forwarding working and I can hit the top index.html page fine. My problem is that when I try to redirect to a JSP's or html page. Tomcat changes the url address from the original which was really the routers name to the localhost's name, which will not work from outside the LAN. Example: router name: MyName.org Tomcat host name: Server So from the outside a URL like http://MyName.org:8080/ goes thru the router and lands on Server:8080 as it should and things work fine. Now within the application there is a redirect to: /project/MyJSP. Tomcat rewrite this as: http://Server:8080/project/MyJSP, but it needs to be: http://MyName.org:8080/project/MyJsp. In other words Tomcat is changing the URL to be the name of the server (as defined by the OS), not the original URL. My server.xml contains: and Any ideas where I am going wrong? -d - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
URL Mapping behind a router
I am deploying my tomcat server behind a router. I have the router port forwarding working and I can hit the top index.html page fine. My problem is that when I try to redirect to a JSP's or html page. Tomcat changes the url address from the original which was really the routers name to the localhost's name, which will not work from outside the LAN. Example: router name: MyName.org Tomcat host name: Server So from the outside a URL like http://MyName.org:8080/ goes thru the router and lands on Server:8080 as it should and things work fine. Now within the application there is a redirect to: /project/MyJSP. Tomcat rewrite this as: http://Server:8080/project/MyJSP, but it needs to be: http://MyName.org:8080/project/MyJsp. In other words Tomcat is changing the URL to be the name of the server (as defined by the OS), not the original URL. My server.xml contains: and Any ideas where I am going wrong? -d - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
