I've worked in the development of JBossProfiler.
It has been pretty stable, even having to download through CVS and generate the .WAR/.SAR at this present time.
Also, at this time, I didn't convert the code for JVMTI (which is a newer version of the API I have used for Java 5). This means you can use the current version without any problem since you don't use any special GC option while capturing the data from your app-Server.
Anyway, if you want to use that and you have a hard time compiling it, let me know them I can provide you a binary distribution.
Information on how to use it is located on the wiki page for JbossProfiler.
The interceptor is a stateless property of the stateless session bean container. The ejb context is associated with the instance cache and hooked into the call via the invocation which serves as the thread local.
Blocking the call until the context is free would be fine and is the default behavior of entity beans.
Capture the output from the jboss-console and see whether the process received a core dump.
We have the same problem on Windows 2000 with JBOSS 3.2.3, the server just stops without displaing any errors.
We have the same problem on linux redhat 9 with 3.2.3 too. If this problem persists, unfortunaly we 'll have to use another server.
We have the same issue - running Solaris 2.6 and JBoss 3.2.1.
Can someone in JBoss please respond to this thread ?
Create bug report on sourceforge with some useful info like the log around the point of shutown. Either someone has invoked shutdown through jmx, or the os has signalled the vm to shutdown via QUIT, or the vm has died. There is no useful information in this thread currently.
The problem about this question is that no information is avaliable. The server is working so far so good and just stops with no error or message. In my company, we are noticed about that when our costumers can not connect to our server. So, whe type in the browser the address and we observe it is not working....
I can only agree with Marcio that it is hardly possible to provide a detailed report or the error log as the server shuts itself down after running for a while for no obvious reason. It does not look like it is in a panic or having a problem with the memory - it seems it has just met some condition and now starts evacuating.
For this is our production environment we cannot increase the logging level for all the org.jboss package tree.
Can you perhaps recommend a sub-package that is worth setting to DEBUG to get a better idea on what is going on underneath ?
Also, to may be give you a clue, I can admit that we started the performance tuning project on JBoss instance when this started to happen.
All we did so far was to set Sun JVM to use -server, -Xms512m and -Xmx1024m.
We are running Jboss 3.2.1 on Solaris 2.6 with applied patches for J2SDK 1.3+ and J2SDK 1.4.2_04.
I'll try that configuration on linux.
So, there has been no description of the log at all in this thread. Its a simple issue, either there is an entry in the log saying the server is shutting down due to an explicit shutdown command, or an implicit shutdown due to a QUIT signal. If this does not exist the vm is crashing and you need to be capturing the standard out/err of the script running the vm lauching jboss to capture any possible error msgs.
I changed the JBoss's start command (LD_ASSUME_KERNEL=2.4.1) and the problem still happens.
Just to be more specific, my problem isn't the shutdown of the server, the real problem is that it's still running but it doesn't answer any request. I type in the browser the webservice's url and a timeout occurs.
The period of time the problem occurs is about once a day.
Márcio S. Manske
I think my problem is exactly the same.
We're running on Red hat 9 as well.
We encounter this on all our jboss 3 servers. This is highly unacceptable.
In past years, we run JBoss 2.2 or JBoss 2.4 without this problem at all.
what is unacceptable is that Scott asked twice for thread dumps and other relevant log entries and you guys didn't provide any so far :(
Give us some meat otherwise we can't help.