Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
János Löbb wrote: On Apr 6, 2009, at 4:10 AM, André Warnier wrote: Caldarale, Charles R wrote: [...] The metaphysical implications of existing without a trace are rather intriguing... I am surprised that you would not have heard of stealth technology. What do they call a stealthy Tomcat ? a Raptor ? No that must be a Schrödingercat :) I am sorry, but I will have to disagree. A Schrödinger Tomcat would be one that exists multiple times, in quantum superposition. Which would probably create problems with all of them trying to listen on the same TCP ports. Unless of course the listening port only gets instantiated at the first interaction with one of the Tomcats. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
On Apr 7, 2009, at 7:57 AM, André Warnier wrote: János Löbb wrote: On Apr 6, 2009, at 4:10 AM, André Warnier wrote: Caldarale, Charles R wrote: [...] The metaphysical implications of existing without a trace are rather intriguing... I am surprised that you would not have heard of stealth technology. What do they call a stealthy Tomcat ? a Raptor ? No that must be a Schrödingercat :) I am sorry, but I will have to disagree. A Schrödinger Tomcat would be one that exists multiple times, in quantum superposition. Which would probably create problems with all of them trying to listen on the same TCP ports. Unless of course the listening port only gets instantiated at the first interaction with one of the Tomcats. OK. :) How about BatCat ? It is stealthy, but still can say: Miaú :) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 4/7/2009 7:57 AM, André Warnier wrote:
A Schrödinger Tomcat would be one that exists multiple times, in quantum
superposition. Which would probably create problems with all of them
trying to listen on the same TCP ports. Unless of course the listening
port only gets instantiated at the first interaction with one of the
Tomcats.
I would think that a Schrödinger Tomcat would be one configured thusly:
1. ROOT context captures all incoming requests and routes them to the
CheckForTomcatRunningServlet.
2. CheckForTomcatRunningServlet is implemented as follows:
public void service(...) {
System.exit(0);
}
Tomcat is either up or not. You are outside the box (ha ha ha) so you
can only check if it's up by sending an HTTP request to it. Is it running?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknboY4ACgkQ9CaO5/Lv0PCyiwCfUtPg9APi+7e5vQ7hKZHC1XWx
9/YAniya2ZZgU6Epe0R9spxHBeprz4s9
=QCAD
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 4/7/2009 7:57 AM, André Warnier wrote:
A Schrödinger Tomcat would be one that exists multiple times, in quantum
superposition. Which would probably create problems with all of them
trying to listen on the same TCP ports. Unless of course the listening
port only gets instantiated at the first interaction with one of the
Tomcats.
I would think that a Schrödinger Tomcat would be one configured thusly:
1. ROOT context captures all incoming requests and routes them to the
CheckForTomcatRunningServlet.
2. CheckForTomcatRunningServlet is implemented as follows:
public void service(...) {
System.exit(0);
}
Tomcat is either up or not.
I would have to disagree again.
The Tomcat you describe above is totally deterministic : it is alive
(since it can receive your request), but as soon as you interact with
it, it dies.
In my view, the Schrödinger Tomcat's existence is never in doubt. There
are even an infinity of them, each one having some probability of being
more or less alive or dead. As soon as you interact with it/them
however, you automatically select one of them.
Thus the code above should at least incorporate the following
pseudo-code modification :
public void service(...) {
if (random(1) 0.5)
System.exit(0);
else
response.print(locale(miaou));
}
The question in fact really boils down to whether these quantums of life
extend or not to the listening port. Can it be for example half-open ?
And is a half-open port 8080 equivalent to a fully-open port 4040, or
does it just have only half the bandwidth ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 4/7/2009 4:29 PM, André Warnier wrote: I would have to disagree again. Sorry, I should have done the code in a haiku. The Tomcat you describe above is totally deterministic : it is alive (since it can receive your request), but as soon as you interact with it, it dies. Hmm... you're right. I was thinking that the System.exit() would kill the process and therefore the connection, but by the time the JVM dies, the connection has already been made, proving the liveness of the instance (nb: Mozilla Thunderbird does not consider 'liveness' to be a correctly-spelled English word). Can [the listening port] be for example half-open ? Perhaps. How about this: ServerSocket socket = new ServerSocket(8080); // No subsequent socket.accept() call And is a half-open port 8080 equivalent to a fully-open port 4040, or does it just have only half the bandwidth ? Half the bandwidth, I think. Half would refer to its openness, not to its port number, but maybe only half of the data gets through per unit time. How many gigabits does the average cat hold? (nb: tb does not consider 'gigabits' to be a correctly-spelled word, though 'gigabytes' /is/). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAknbufcACgkQ9CaO5/Lv0PANUQCXd3QHBarYGT4YouC4saqc27xM sgCgjILsEbGDO3+rKWZGx2aUZ7znzPY= =EpK1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
Hi there, 2009/4/6 Caldarale, Charles R chuck.caldar...@unisys.com: The metaphysical implications of existing without a trace are rather intriguing... Yeah, I was about to call Mulder and Scully to investigate it, but I thought I'd give the user list a chance first. Looks like it. In Tomcat 5.5, there was a non-daemon thread for each Connector named http-port-Monitor; this thread no longer exists in 6.0, since the whole area appears to have been re-architected. There are no non-daemon threads in Tomcat 6.0, other than the whatever thread gets the game started; the normal Tomcat bootstrap uses this lead thread to listen on the shutdown port. You'll need to have some thread hanging around to keep the JVM from terminating; if you don't have such a thread, why are you bothering with embedded? I usually ran the app with the GUI, but sometimes it is useful to ran it without, specially during development and testing of new containers, as I don't have to wait for the Windows to open. I did not know it was disallowed. OTOH, if I did not want my app to start alive, why would I have started a server listening in a port? I use embedded to test web applications and to run them inside Ant so I can perform integration tests on them within Ant, so the GUI part is optional. if I start the server with a GUI window, so the container remains alive due to the GUI thread, stopping the server does not really work, as even though it says that the Connector stopped, I can still access the server for some seconds and then it starts answering resource not available, but the thing is, it still answers to the port. It's your responsibility to terminate your GUI thread so the JVM can kill off all the daemon threads. Do you mean that the stop() method on the Server class is useless and in order to stop the embedded server I have to kill my whole application? That doesn't make much sense. You really use this. everywhere? Seems a bit tedious, to say nothing of making code reviews difficult. this is added automatically by the IDE and in this case, it helps me distinguish between the objetcs that are created on the start method and the ones I have to keep a reference to. You have to change your code; you got lucky in 5.5. To me it makes more sense the 5.5 behaviour, but oh well :). In any case, not being able to stop the server normally without killing my whole application is really a non-no for me. Yes, the doc could be improved here. You could create a FAQ/Wiki entry based on your findings. Once I get a clear picture, I'll try to. - Chuck Thanks for your help, D. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
Caldarale, Charles R wrote: [...] The metaphysical implications of existing without a trace are rather intriguing... I am surprised that you would not have heard of stealth technology. What do they call a stealthy Tomcat ? a Raptor ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded I am surprised that you would not have heard of stealth technology. What do they call a stealthy Tomcat ? a Raptor ? I think it will be the Lightning II; the US Navy passed on the Raptor (puts on a good show at Oshkosh, though). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
On Apr 6, 2009, at 4:10 AM, André Warnier wrote: Caldarale, Charles R wrote: [...] The metaphysical implications of existing without a trace are rather intriguing... I am surprised that you would not have heard of stealth technology. What do they call a stealthy Tomcat ? a Raptor ? No that must be a Schrödingercat :) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
Hi there, I have an application that uses Tomcat as embedded engine and so far I was using version 5.5 of Tomcat. I wanted to upgrade to version 6.0.18 and I've found some issues due to the different behaviour and I don't see any difference in the API or articles I've found so I wonder what I'm doing wrong. The first problem is that, after using Server.start(), unless I have another living thread, the program will exit even though I have the container started and supposedly listening on the port. I have tested that the server indeed works and listens to that port, but when my other threads finish, the container simply exists without a trace. I've seen a thread in the tomcat-dev list (embedded tomcat 6 14 Feb 2008) that seems to imply this is normal with Tomcat 6, but in Tomcat 5.5 this did not happen. Is this normal? On the other hand, if I start the server with a GUI window, so the container remains alive due to the GUI thread, stopping the server does not really work, as even though it says that the Connector stopped, I can still access the server for some seconds and then it starts answering resource not available, but the thing is, it still answers to the port. And I starting the server again does not fix it. On the other hand, with Tomcat 5.5 I am able to stop the server, and it stops answering at the port, so I am also able to start it again. Using exactly the same code. The code looks like this: -- this.theEmbedded = new Embedded(); this.theEmbedded.setCatalinaHome(new File(tomcat_6).getAbsolutePath()); // Add the engine this.engine = this.theEmbedded.createEngine(); this.engine.setName(Catalina); this.engine.setDefaultHost(localhost); // Create the host this.host = this.theEmbedded.createHost(localhost, .); this.engine.addChild(this.host); this.theContext = this.theEmbedded.createContext(/, this.theConfiguration.getBasePath()); this.theContext.setReloadable(false); this.host.addChild(this.theContext); this.theEmbedded.addEngine(this.engine); // Add a conector this.connector = this.theEmbedded.createConnector((java.net.InetAddress) null, this.port, false); this.theEmbedded.addConnector(this.connector); this.theEmbedded.start(); -- Stopping it is quite simple: this.theEmbedded.stop(); -- So, is the Tomcat 6 embedded engine broken or do I have to change the code? Nothing in the API seemed to indicate any changes needed but... who knows? :) Thanks for your help, D. PD: I can provide more information like libraries used and log traces, but I did not want to make this message too long, in case it was something obvious I had missed. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded
From: d.lope...@gmail.com [mailto:d.lope...@gmail.com] On Behalf Of Daniel Lopez Subject: Tomcat 5.5 embedded vs Tomcat 6.0.18 embedded when my other threads finish, the container simply exists without a trace. The metaphysical implications of existing without a trace are rather intriguing... I've seen a thread in the tomcat-dev list (embedded tomcat 6 14 Feb 2008) that seems to imply this is normal with Tomcat 6, but in Tomcat 5.5 this did not happen. Is this normal? Looks like it. In Tomcat 5.5, there was a non-daemon thread for each Connector named http-port-Monitor; this thread no longer exists in 6.0, since the whole area appears to have been re-architected. There are no non-daemon threads in Tomcat 6.0, other than the whatever thread gets the game started; the normal Tomcat bootstrap uses this lead thread to listen on the shutdown port. You'll need to have some thread hanging around to keep the JVM from terminating; if you don't have such a thread, why are you bothering with embedded? if I start the server with a GUI window, so the container remains alive due to the GUI thread, stopping the server does not really work, as even though it says that the Connector stopped, I can still access the server for some seconds and then it starts answering resource not available, but the thing is, it still answers to the port. It's your responsibility to terminate your GUI thread so the JVM can kill off all the daemon threads. The code looks like this: -- this.theEmbedded = new Embedded(); this.theEmbedded.setCatalinaHome(new File(tomcat_6).getAbsolutePath()); // Add the engine this.engine = this.theEmbedded.createEngine(); this.engine.setName(Catalina); this.engine.setDefaultHost(localhost); // Create the host this.host = this.theEmbedded.createHost(localhost, .); this.engine.addChild(this.host); this.theContext = this.theEmbedded.createContext(/, this.theConfiguration.getBasePath()); this.theContext.setReloadable(false); this.host.addChild(this.theContext); this.theEmbedded.addEngine(this.engine); // Add a conector this.connector = this.theEmbedded.createConnector((java.net.InetAddress) null, this.port, false); this.theEmbedded.addConnector(this.connector); this.theEmbedded.start(); You really use this. everywhere? Seems a bit tedious, to say nothing of making code reviews difficult. So, is the Tomcat 6 embedded engine broken or do I have to change the code? You have to change your code; you got lucky in 5.5. Nothing in the API seemed to indicate any changes needed Yes, the doc could be improved here. You could create a FAQ/Wiki entry based on your findings. - 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
