Is there any configuration for JBoss Application Server's Log configuration
where in the logs get deleted automatically if the log size exceeds some threshold or if it is older than a certain date ?
I believe there is no way to delete them, but you could use the RollingFileAppender. There, you can specify the file size limit like:
<param name="MaxFileSize" value="1000KB"/>
Related
for performance reason I have set the property autofush=false in the subsystem urn:jboss:domain:logging:
<periodic-size-rotating-file-handler name="FILE" autoflush="false">
WildFly does not immediately flush the server.log file but does so according to some policy of its own.
In some scenarios, however, it is necessary to have the latest information available in the server.log without wait that WildFly decides to flush
I have seen that it is possible to change the autoflush flag setting 'on the fly' using wildfly's management console: this causes an immediate flush of the latest information in the server.log but also changes the configuration of xml file of the application.
The best option would be to be able to force the flush on demand without the need to change the application configuration file, but after several searches I have not found any way to do this.
I only found a less-than-elegant way: run a bunch of useless System.out in order to force JBoss to flush
I also tried putting in an application:
System.out.flush();
But no flush is executed.
I have tried using WildFly 26
I have a project with jetty webserver.
The app is up and works fine. After some period (don't know exactly when) if I try to access the app I receive:
"The page you are looking for is temporarily unavailable. Please try
again later."
The app has schedulers set as well. I would be suspicious for timeout but it's not the case. By analyzing the logs I noticed: 2017-12-08
12:45:24.566:WARN:oejsh.ErrorHandler:qtp1555845260-195: Error page
loop /error/not-found.faces.
I don't see any other logs which can cause the issue. Any suggestions for solution?
The likely case is that you have the default work/temp directory setup in your Jetty deployment and there is a process on your machine that periodically cleans up the system temp directory.
Would suggest you specify the work directory or the temp directory (either jvm temp, jetty.base temp, or webapp temp).
See previous answers on how to configure the work / temp directory.
How to change the temporary directory in jetty9?
Jetty: Starts in C:\Temp
I have a .nfy dump file in my client system which is taking too much space. It has been last updated on 4 August. Will it be OK if I delete it? Will it be permanently deleted or DB2 will create a new one?
Yes, it is perfectly safe to delete the administration notification log file, and yes, it will be re-created as necessary by the instance.
You can also enable automatic rotation of this file and the diagnostic log file (db2diag.log) by setting the diagsize instance configuration parameter, for example
db2 update dbm cfg using diagsize 1024
The command above instructs the instance to create 10 rotating log files, each with the maximum size of 1024 MB. Once the 10th file reaches the maximum size, the oldest of the 10 files will be deleted and a new file created.
Note that you will need to restart the DB2 instance for the new parameter value to take effect.
More info here.
We upgraded from JBoss 4 (and JDK 5) to JBoss 5 (and JDK 6). The problem is that the start time has gone from 1.5 minutes (on JBoss 4) to more than 4 minutes.
18:53:35,444 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 3m:9s:262ms
It seems like the component that is taking JBoss the longest time to initialize is the JMX
18:50:41,926 INFO [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl#1adc122[ defaultDomain='jboss' ]
18:52:38,797 INFO [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://lharel2/jndi/rmi://lharel2:1090/jmxconnector
From the DEBUG server log, I get these lines at the problematic time:
2009-12-18 18:51:00,886 DEBUG [org.jboss.deployment.MappedReferenceMetaDataResolverDeployer] (main) vfsfile:/C:/QC/Views/QCDev/jboss-5.1.0.GA/server/default/deploy/jmx-console.war/ endpoint mappings:
2009-12-18 18:51:00,886 DEBUG [org.jboss.deployment.MappedReferenceMetaDataResolverDeployer] (main) Processing unit=jmx-console.war, structure: jmx-console.war
2009-12-18 18:52:35,209 DEBUG [org.jboss.deployment.OptAnnotationMetaDataDeployer] (main) Deployment is metadata-complete, skipping annotation processing, ejbJarMetaData=null, jbossWebMetaData=org.jboss.metadata.web.spec.Web23MetaData#1f, jbossClientMetaData=null, metaDataCompleteIsDefault=false
There is no EJB in the project.
The memory settings are:
-Xms128m -Xmx512m -XX:MaxPermSize=256m
Do you have any idea how JBoss start time can be improved?
Update: so far no luck, I tried shreeni's suggestion (changed the scanning xmls). The server is not running in debug mode so MicSim's suggestion is not relevant
A shot into the blue sky without more information
Network timeouts: 1,5 minutes of delay when deploying jmx-console.war may indicate a network timeout (e.g. 3 x 30 seconds). Try to start JBoss and bind it to a specific IP address using the -b command line argument or the jboss.bind.address system property. Also, try to make sure your host and DNS resolution settings on your system are correct.
JMX is also using RMI and you may want to set the RMI server host name as system property. On some Linux distributions, RMI has problems with looking up the correct hostname and jmx-console.war may try to connect to the 'wrong localhost'. The system property is java.rmi.server.hostname
System tracing: If that does not help, you may want to use strace to start the java process, so you can see the point where the system hangs (if it really does hang due to a network timeout or similar).
That is an awfully big gap in the logs. I suggest changing the log configuration to log everything at DEBUG level, rather than INFO. This will generate an awful lot more log entries, but hopefully will help you narrow it down.
The easiest way to do this is to set the -Djboss.server.log.threshold=DEBUG system property when you start JBoss
I had an issue like this but I found a good improvement by setting the initial and max heap size to same values, I mean:
-Xms512m -Xmx512m
With this, I improved from 4 to 2 minutes the starting time.
Your suspicion about the jmx-console can be misleading. There may be other components doing work in the background unrelated to the jmx-console. In my experience, we had an issue where a small war file appeared to take 3 minutes to load! It was innocent. The culprit was partly due to an EAR file with many wars and jars.
While I'm no expert, I would suggest the following:
Try turning up the logging to TRACE. By doing this, I witnessed one of the deployers (EJBDeployer, I think) unnecessarily scanning WARs in one of our EARs. I then manually disabled the scanning of those WAR files.
Run wireshark during the startup. I discovered some war files were hanging while waiting for a response from an external DTD request. Those websites were either now non-existent or would not properly serve the DTD files to java-based programs. I could speed it up by either having the programmers use local DTD files or mirroring those DTDs locally and having /etc/host loopback locally.
You could refer to this link to avoid unnecessary annotation scanning which could speedup your server start
See http://community.jboss.org/wiki/jboss5xtuningslimming especially the "Tuning" part.
I'm using JBoss 5.1.0 with a Macbook pro (2.26ghz 4gb) without applications it start in 54s
15:00:26,449 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 54s:720ms
I made a new configuration based on the "default". The JMS dataosurce points to a Postgres database instead of the "Hypersonic Database" (in memory database)
I suppose you are starting in debug mode. This mode can be up to 3 times slower than normal mode.
But there might be also a problem when switching from JDK5 to JDK6. I found this solution here on the net:
I've solved that. It's a debugging issue. I've changed my debug settings from:
wrapper.java.additional.26=-Xdebug
wrapper.java.additional.27=-Xnoagent
wrapper.java.additional.28=-Djava.compiler=NONE
wrapper.java.additional.27=-Xrunjdwp:transport=dt_socket,address=7199,server=y,suspend=n
to:
wrapper.java.additional.26=-Xdebug
wrapper.java.additional.27=-Xrunjdwp:transport=dt_socket,address=7199,server=y,suspend=n
and JBoss becomes fast again.
Hope this helps.
Do you need the JMX console application? Pragmatic thing would be to un-deploy it from the server, you could still use the jconsole or jvisualvm for basically the same thing.
Turn off annotation scanning and other features you don't need https://community.jboss.org/wiki/jboss5xtuningslimming
When you start/stop JBoss from eclipse, it does not clean up the tmp & work folders correctly. Setup an External Tool configuration and run a batch file to delete everything in tmp & work folders before each startup.
I was able to speedup running the "default" profile from 15/20 minutes to 5 minutes.
By default when using a webapp server in Eclipse Web Tools, the server startup will fail after a timeout of 45 seconds. I can increase this timeout in the server instance properties, but I don't see a way to disable the timeout entirely (useful when debugging application startup). Is there a way to do this?
In Eclipse Indigo, you can edit the default timeout by double-clicking on the server in the "servers" view and changing the timeout for start (see graphic). Save your changes, and you're good to go!
On the EclipseIDE, double click on the server
Admin panel opens up, click on the "Timeouts" tab
Put larger value in the "Start (in seconds)", may be 1800
Restart/Start the server
If everything is okay, the server should start.
Just another data point. If you see in your Console "Server startup in NNN ms", but the Server view still shows that it is trying to start, and then times out eventually killing the server, it might be that you have no plain HTTP connector configured. For example, if you have only a 2-way SSL connector configured in your Tomcat, it will start fine with the scripts in "TOMCAT_HOME/bin", but if you try to start it with the Eclipse Server view, it won't be able to open a connection to the HTTP port, and will terminate when it hits the timeout. (This was with a fairly old STS 2.1.0. Don't know if it's fixed in later versions)
Joe
Julie's answer gives you a long timeout, but not unlimited. You can move the server configuration file to the workspace, and then edit the xml file directly and set a limit greater than 1800. It's an ugly hack, but should work.
Goto Window > Preferences > Server
Set 'Server timeout delay' as Unlimited from drop-down menu.
or
Goto $WORKSPACE/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.wst.server.core.prefs
Add/update line machine-speed= -1
here, -1 ~ Unlimited
If you still has issue after changing timeout settings, then it's best to remove the server configuration in Eclipse (in Server view tab) and re-create it again.
Server --> New Server.
It worked for me.
yes this works, but the maximum limit is 1800, which is 30mins.
Sometimes when rebuilding our entire database (on server initial start) this can go for longer than 30mins and causes problems.
In eclipse 2019-09 (4.13.0) there is no UI capability to set an unlimited value. It must be between 1 and 84600 seconds (a day).
But if you edit the .metadata/.plugins/org.eclipse.wst.server.core/servers.xml file in the workspace and set the server's start-timeout attribute to a large number of in my case -1 it will not abort the server startup until such time is reached. I had to restart eclipse for the change to be read.
NOTE: using the UI to edit other values will coalesce your value to a value within the allowable range.