I have created a war application and it was tested both in weblogic 12c and Jboss EAP 6.2 successfully.
I changed application server, i moved to JBoss EAP 6.3 and the application could not work properly. Suddenly Jboss stopped to serve any requests and the existing requests were waiting for ever.
I have started Jboss in debug mode from netbeans and i run my application in debug mode.
I have noticed that every time the server was stopping at the System.out.println(); command.
After server's crush/stuck, i interrupt the last thread which was at the log file and upon the interruption i see at the netbean's debugging console a notice:"stopped at AppenderSkeleton.java:231" The previous call at the code is a the line that calls system.out.println.
When i removed all the system.out.println from my code and i left only my log4j the application did not stuck again. I am still testing because i don't know for sure if this is the problem.
Does anyone else had the same problem? When the System.out.println was called one a time it seems that there is no problem, but when this method is called from multiple methods then it seems to stuck.
You probably use a custom log4j configuration in your deployment. It requires a special care as explained by the JBoss logging developer James Perkins in this JBoss forum comment.
Your problem could be related to changes between EAP 6.2 and EAP 6.3 introduced by following bugfix:
Bugzilla: System.out.println() doesn't work when using per-deployment logging
Other users experience similar issue as described in
Bugzilla: ConsoleAppenders can deadlock if included in application log4j configs
If you have some additional info, feel free to comment on existing bugzillas or create a new one where you describe your application (mainly logging) configuration.
Related
is there any migration guide available for application Server Glassfish to JBoss 6 EAP. I am particularly intrested in server side configuration(Installing, configuration etc) and the important points taken into account if any while migration (Except the code changes)
I believe something is being worked on, but it says it's coming soon. Your best bet for now would probably be to ask in the forums or if you have a support contract for EAP 6 there might be some other types of help available.
I couldn't find an answer to this in any other questions and I wanted to see if anyone knew. I'm using JBoss AS 7.1 on Kepler eclipse, and I was wondering if there is a way to change your standalone.xml while the server is running and have Jboss push the change. Would just cleaning the server do this?
You can't edit the raw XML files and see runtime changes. In fact there is a good chance any changes will be overwritten by the server.
The best way to make runtime changes is either via the web console or the CLI environment. I don't know if JBoss Tools has any kind of CLI type of client that can be used.
I am using Glassfish v3.0.1 for my project. However, Glassfish seems to be down many times. Therefore, I want to develop a mechanism that notifies me whenever Glassfish is down. Is there any option in Glassfish? If not, how can I achieve this? Further, how can I understand why Glassfish goes down? I cannot find proper explanations in logs.
I'm not aware of any options in Glassfish itself and I doubt there are any (it's usually hard for a process to know when it's dead :-). Write a script that tries to connect to the service (for example, using wget or curl) or use a system monitoring tool that watches processes.
To find out why Glassfish terminates, you must debug the problem. Here are some tipps:
Add/enable more logging
Search the source code for System.exit(). This can terminate an Java app without any trace of why it happens. (this might help, too)
Check the standard output of the process
Look for crash dumps; see the documentation of the Java VM which you're using.
I am have to develop an application based on Spring AOP that adds trace Id and loggers to existing application in live production.
The new aop application needs to be packaged onto jars and is to be deployed on code in production. But the production code is running on weblogic server and I don't have option to stop the already running weblogic servers.
Can any body help or give me the clue on how to introduce this new jar to the running application on weblogic.
Thanks in advance.
It's a bit late , but i found this question while searching for the same thing.
The nostage mode can help you with this,I tried it for JSP's and it works great , not sure about the jars though
These links are useful , they might help --
http://docs.oracle.com/cd/E11035_01/wls100/deployment/deploy.html#wp1024366
How do I refresh jsp's on weblogic
I have a GF3 server in production. Sometimes, it just stops responding. At least, all web applications do. CPU / memory usage is low, but I can't get any web app on port 8080 to work. Nothing in the logs (5 minutes gap in server.log until I restarted manually). Everything fine after restart... for a while.
Took a jstack output before restarting. Didn't find anything interesting (no code from my apps running, no locks...).
Version = GlassFish v3 (build 74.2), JRE version 1.6.0_19
UPDATE: it comes back by itself after some time (still not acceptable for my clients :-( )
UPDATE: I switched to a new installation of GF3.1 (was 3.0.1). At the moment (after a couple of hours), one of the applications that is deployed there has 177 sessions. Problem is: I only have about 12 users (where did all those sessions come from?). Same applications deployed with other name has 6 sessions. Could I just run out of thread pools or something like that?
I suggest hooking up Visual VM with the GF plugin.
http://visualvm.java.net/index.html
Then when your server "stops", take a look and see what's going on.
If there's nothing interesting in the stack trace, then the problem is likely to be between the client and GlassFish.
In any case I would also suggest upgrading to the latest JDK (_24) and GlassFish (3.1).
I was using connection pooling with MySQL, and in some places I forgot to close the database connection. After fixing those mistakes everything was fine.