RE: [JBoss-user] Apache+Tomcat+JBoss
We had a similar problem on my last project. We ended up just using brute force to solve the situation, we had tomcat and apache serving from a specific directory. This directory would actually be a symlink to the latest version of the code. We modified our Ant build script to generate the war file (we were not using JBOSS) and name it according to the date. This file was then moved to the proper environment (QA, Staging, Production) and another script would unwar it into a directory based on its name(we would unwar the file skipping jsps and code on the web servers, and html, images, etc. on the app servers). The symlink would then be updated to point at the latest code. This is a major hack and lost most of the benefits of packaging the application, but it was quick and easy, and did have the benefit that rolling back to an older version of the application was as simple as changing a symlink. This made debugging much easier. Samuel -Original Message- From: Jim Crossley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 20, 2001 13:41 To: [EMAIL PROTECTED] Subject: [JBoss-user] Apache+Tomcat+JBoss We're currently deploying our web apps (packaged as war files) on Apache+Tomcat 3.2, and it works fine, except for one problem. We'd like to be able to redeploy our apps independently of each other, without having to stop and restart Tomcat. Though we currently don't use EJB's in our apps, the JBoss J2EEDeployer is enough of a reason for us to integrate JBoss into our environment. Everything works great between JBoss and Tomcat, but I'm having a hard time deciding how to integrate Apache. I've searched the archives, and there seems to be no reasonable way to split the serving of static and dynamic content between Apache and Tomcat, respectively. The two solutions proposed are best summarized in these two messages: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg02681.html http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg01839.html With all due respect -- I understand the complexity of the problem -- these solutions are unacceptable to us, the first because Tomcat is still serving both static and dynamic content, and the second because it defeats the purpose of the war file, making deployment even more error-prone than it already is. Is there a better way? Thanks. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] jBoss architecture question
Yes, you are quite right. However, we are, as you say stuck with whatever implementation is made by the JVM. Other than wrapping some native C code to handle signals and then communicate them to the java threads using some means, like sockets, there is nothing that can be done. It seems simple enough to test this on whatever implementation you happen to be on. Write a small program that spawns some threads, kill -TERM pid one of the threads and see what happens. Most likely you will have to do this for every VM and OS you routinely use. I know that we here have scripts that kill iPlanet threads automatically to keep the app server from dying, I do not know if these scripts are sending TERMs or KILLs though. This of course might work on a website where the only thing that is lost when the thread is killed is the request, it would not if there are interdependencies between threads. Samuel -Original Message- From: Michael Bilow [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 13:36 To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-user] jBoss architecture question No, no... I agree that, in the abstract, it makes sense to send the TERM signal only to the initial or master thread. Furthermore, I entirely agree with you that it might be appropriate for a thread to ignore TERM if the necessary shut down processing is handled by the master thread. There is no way, at least on Linux, to distinguish processes and threads from userland. A thread has a process ID (pid) and runs on the system scheduler just like any other process. The distinction between a process and a thread in Linux is made in terms of kernel memory mapping during task switching, since the defining characteristic of a thread is that it shares the complete memory descriptor table of all other fellow threads. The end result is that threads show up on the process list because they have pids and they are therefore subject to being sent signals. This is absolutely unavoidable in a Linux environment. Therefore, there must be some facility in each thread to handle signals when they are sent. If the proper behavior is for threads to ignore TERM signals, then they must install handlers to do so. If the threads should ignore signals and they do not, then the application is, in fact, unstable. If the JVM can be depended up to sort this out and call the signal handler in the master thread even when the signal is actually sent by the system to the child thread, then that is a solution. However, I do not know enough about the internals of any JVM to be sure that this is the case, and I doubt that such behavior is guaranteed to occur on every JVM even if it does occur on some JVMs. The Sun and IBM JVMs might do exactly opposite things in this regard, although I have no idea what they do. This discussion arose because, in the quoted post to the list, danch said that it was a bad thing to send TERM to child threads and that TERM should should only be sent to the master thread. So the issue for me is what happens if TERM is sent to all of the threads instead of just the master thread? Are the TERM signals sent to the child threads ignored, which would be fine? Are the TERM signals sent to the child threads reflected by the JVM to the master thread, which would also be fine? Or do the TERM signals sent to the child threads pass through unhandled and kill those threads abruptly, which presumably would NOT be fine? -- Mike On 2001-05-13 at 02:35 -0400, Samuel Bucholtz wrote: > This is not 100% true. On Unix any process should expect to receive and > handle a TERM signal. > Threads on the other hand do not need to and should not be expected to > handle a TERM. Remember, threads only act and look > like processes when using native threads as opposed to pure java threads. > The threads, logically, must act the same and > be as similar as possible whether Native or Pure. Since pure threads run > within the JVM process and will never see or > handle a signal, there is no reason to expect the native threads to do so > either. > Rather, in the case of some kind of impending shutdown, etc. the signal > should reach the master process which spawned > (and therefore controls) the threads. It is that processes responsibility to > gracefully stop the threads, flush buffers, > sync files, etc. > A thread does not control its resources, scheduling, etc. It may or may not > even be able to communicate with it's > scheduler/parent. There is no way to expect it to be able to receive a TERM > and know how to handle it in a graceful manner. > As long as the parent can control/stop threads, and do the proper thing when > it received a signal, there is no reason to consider the application > unstable, just because the threads ignore signals. > > Samuel > > -Original Message- > From: Michael Bilow [mailto:[EMAIL PROTECTED]] > Sent: Sunday
RE: [JBoss-user] jBoss architecture question
This is not 100% true. On Unix any process should expect to receive and handle a TERM signal. Threads on the other hand do not need to and should not be expected to handle a TERM. Remember, threads only act and look like processes when using native threads as opposed to pure java threads. The threads, logically, must act the same and be as similar as possible whether Native or Pure. Since pure threads run within the JVM process and will never see or handle a signal, there is no reason to expect the native threads to do so either. Rather, in the case of some kind of impending shutdown, etc. the signal should reach the master process which spawned (and therefore controls) the threads. It is that processes responsibility to gracefully stop the threads, flush buffers, sync files, etc. A thread does not control its resources, scheduling, etc. It may or may not even be able to communicate with it's scheduler/parent. There is no way to expect it to be able to receive a TERM and know how to handle it in a graceful manner. As long as the parent can control/stop threads, and do the proper thing when it received a signal, there is no reason to consider the application unstable, just because the threads ignore signals. Samuel -Original Message- From: Michael Bilow [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 2:10 To: List: jBoss users Subject: Re: [JBoss-user] jBoss architecture question On 2001-05-11 at 22:09 -0500, danch wrote: > Jim Archer wrote: * * * > > All the threads also raise a shutdown question. We have written an > > init.d script to gracefully start and stop jBoss as a server task, in > > the same manner as other Debian processes. If the script issues a kill > > to each thread, will this produce a gracefull shutdown, or will it > > terminate each thread ungracefully? > > > > The kill should be sent to the parent of all the threads. If you look at > ps -axf output you'll see that run.sh spawns one process, which is then > the parent for all the threads. A change in run.sh to save the pid of > the java process into a file in var would be the best way to accomplish > this. I have a concern about this. On Unix, any process/thread should expect to receive a TERM signal and is obligated to handle it appropriately. If the process/thread elects not to install a handler to catch the TERM signal, then the default is for the system to kill the process abruptly, which is usually inappropriate for anything except the most trivial programs. It is not possible on Unix to guarantee that the graceful shutdown script will always be followed so that the right signals are sent to the right recipient processes/threads. In the case of a power failure notification from a UPS daemon or an emergency shutdown initiated by the watchdog daemon, a TERM signal will be sent directly to every process/thread. The process/thread TERM handler should then do whatever is necessary to close files, commit data, notify network partners, and otherwise assure at least a stable shutdown if not a graceful one. If a process/thread elects to catch TERM and do something in response, then it had better do it fairly quickly because, if time runs out, then the system can be expected to send the uncatchable KILL signal and then the process/thread is guaranteed to go down hard. Really bad things can then happen, such as the filesystem being closed with process/thread data uncommitted to disk. For a process/thread to be considered stable on Unix, it _must_ catch and handle the TERM signal intelligently if failing to do so would lead to data corruption or other instability. This means that it should be safe for every thread in jBoss, whatever it may be doing, to be sent TERM asynchronously in indeterminate order, and it must also be safe for any of these threads to be sent TERM more than once. -- Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Is there a step by step guide to porting apps fr om iPlanet Applic ation Server to JBoss?
Sure, I would be happy to point out the differences. These are the
descriptors being used (note I did not write most of this, so I am not 100%
sure what everything is doing. I am still chewing on this problem with the
JSP:include tag and being unable to run the app using the ear file.
iPlanet-
# cat ias-ejb-jar.xml
http://developer.iplanet.com/appserver/dtds/IASEjb_jar_1_0.dtd'>
GameStateController
{053B8760-D462-11D4-A3E6-0010A4C171BC}
0
false
false
0
DBWrapper
{2ccca1f8-824a-45de-8576-0832e7b7804e}
0
false
false
0
oltp
jdbc/mlb/oltp
qry
jdbc/mlb/qry
OrderProcessor
{6492365d-29e9-42c3-8d1b-5883e7a819c3}
0
false
false
0
UserProfileAdmin
{21937580-9944-11d4-a08a-64657374}
0
false
false
0
ejb/LdapAdmin
ejb/LdapAdmin
LdapAdmin
{1f7166f0-957c-11d4-a083-0010a4c4739b}
0
false
false
0
Admin
{075444e1-b4fe-11d4-a0b4-0010a4c4739b}
0
false
false
0
jBoss-
# cat jboss.xml
GameStateController
GameStateController
DBWrapper
ejb/DBWrapper
qry
jdbc/mlb/qry
qry
^M
oltp^M
jdbc/mlb/oltp^M
oltp
OrderProcessor
OrderProcessorEJB
UserProfileAdmin
UserProfileAdminEJB
ejb/LdapAdmin
LdapAdmin
LdapAdmin
LdapAdminEJB
Admin
AdminEJB
-Original Message-
From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 11:27
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Is there a step by step guide to porting apps
fr om iPlanet Applic ation Server to JBoss?
What sorts of features are you using that JBoss doesn't support?
Specifics here could save others headaches later on (and some might get
implemented).
-danch
Samuel Bucholtz wrote:
> I fixed the descriptors, though there are a few things I had to rip out
> because JBoss does not support them that may or may not cause me problems
in
> the future. They seem to work fine right now, most of my problem was that
I
> wrote none of the code, so I was not sure what was doing what. ;-)
>
> Samuel
>
> -Original Message-
> From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 17:44
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] Is there a step by step guide to porting apps
> fr om iPlanet Applic ation Server to JBoss?
>
>
> Samuel Bucholtz wrote:
>
>
>>Thanks,
>>
>>It is actually pretty simple. There are only a few beans and no entity
>>
> beans
>
>>at all.
>>
>>I just keep getting the same error, and have no clue what it is trying to
>>ask for.
>>
>>org.jboss.ejb.DeploymentException: expected only one assembly-descriptor
>>
> tag
>
>
>
> If you're still having problems with this, send me your descriptors.
>
> -danch
>
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Is there a step by step guide to porting apps fr om iPlanet Applic ation Server to JBoss?
I fixed the descriptors, though there are a few things I had to rip out because JBoss does not support them that may or may not cause me problems in the future. They seem to work fine right now, most of my problem was that I wrote none of the code, so I was not sure what was doing what. ;-) Samuel -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 17:44 To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Is there a step by step guide to porting apps fr om iPlanet Applic ation Server to JBoss? Samuel Bucholtz wrote: > Thanks, > > It is actually pretty simple. There are only a few beans and no entity beans > at all. > > I just keep getting the same error, and have no clue what it is trying to > ask for. > > org.jboss.ejb.DeploymentException: expected only one assembly-descriptor tag > If you're still having problems with this, send me your descriptors. -danch ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Problem with JSP Includes
I want to thank people for their help yesterday, I managed to get the dtd and create the proper jboss.xml. I am now able to load the jar file of EJBs and the run and are verified just fine. I have run into a few other problems: 1. I have an ear file with the EJB jar file and a war file with all the jsps, etc. for the app. If I put the ear file in the deploy directory the war file craps out with a: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet 2. If I put the EJB jar file in the deploy dir and make a symlink from within the tomcat webapps dir to a place on the filesystem where the war file has been extracted the application seems to load. However, I get another problem: When I access a JSP I get the following error in JBoss: JSP:include tag is invalid. This seems to happen because the JSP is referencing an "absolute" path from the root of the application, rather than a local relative path. I have been unable to find anyway to get the JSP:include to work. Samuel > ________ > Samuel Bucholtz > [EMAIL PROTECTED] > 1.917.534.8640 > Scient* - The eBusiness Systems Innovator(tm) > http://www.scient.com > > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Is there a step by step guide to porting apps from iPlanet Applic ation Server to JBoss?
Thanks, It is actually pretty simple. There are only a few beans and no entity beans at all. I just keep getting the same error, and have no clue what it is trying to ask for. org.jboss.ejb.DeploymentException: expected only one assembly-descriptor tag Samuel -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 20:12 To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Is there a step by step guide to porting apps from iPlanet Applic ation Server to JBoss? Samuel Bucholtz wrote: > Hi, > > I am trying out porting a site from iPlanet to JBoss/Tomcat/Apache. > Currently, I ran into a stumbling block creating the JBoss XML Descriptor. > 1. There is almost no documentation on the Descriptor. take a look at jboss.dtd You might need to grab that out of CVS. > 2. The iPlanet descriptor we have does a lot more than just map jndi names. What does it do? Be aware that CMP can use jaws.xml in addition to jboss.xml. -danch ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Is there a step by step guide to porting apps from iPlanet Application Server to JBoss?
Hi, I am trying out porting a site from iPlanet to JBoss/Tomcat/Apache. Currently, I ran into a stumbling block creating the JBoss XML Descriptor. 1. There is almost no documentation on the Descriptor. 2. The iPlanet descriptor we have does a lot more than just map jndi names. Is there an easy way to do this? The site currently gets almost a million hits an hour, I really would like to see what level of performance I can get using JBoss and Tomcat. Any other suggestions? Samuel ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
