In installed Artemis broker logging.properties, i have included below configuration to setup log rotate
# File handler configuration
handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
handler.FILE.level=DEBUG
handler.FILE.properties=suffix,append,autoFlush,fileName
# for log rotate
handler.FILE.suffix=.yyyy-MM-dd-HH-mm
handler.FILE.append=true
handler.FILE.autoFlush=true
handler.FILE.fileName=${artemis.instance}/log/artemis.log
handler.FILE.formatter=PATTERN
## Added for Log rotate
handler.FILE.rotate-size=25k
handler.FILE.max-backup-index=3
handler.FILE.rotate-on-boot=true
With above change when i restart the Artemis broker service, is notice the log being rotated to artemis.log.2021-09-02-14
But with the rotate-size 25k, the file is not getting rotated.
Below is the jboss documentation for the properties.
properties
data type
description
max-backup-index
Integer
The maximum number of size-rotated logs that are kept. When this number is reached, the oldest log is reused. Default: 1. This setting only applies to logs that are rotated based on file size. Note that if a file is rotated with a date format suffix, it will not be purged using the max-backup-index option.
rotate-size
String
The maximum size that the log file can reach before it is rotated.
My expectation in this case would be:
every hour the log to be rotated, and only 3 set of files will be manage
artemis.log
artemis.log.2020-09-02-16
artemis.log.2020-09-02-15
artemis.log.2020-09-02-14
purged files
artemis.log.2020-09-02-13
Is there a way to check how often the log rotation is triggered by Artemis broker?
Is the configuration incorrect.
Using Artemis 2.17 version
After updating the properties, i am getting below exception on restarting the service.
2021-09-03 02:02:59,468 WARN [org.apache.activemq.artemis.core.server] AMQ222276: Failed to process changes to the logging configuration file: file:/<borker-path>/etc/logging.properties: java.lang.IllegalArgumentException: No property "rotateSize" setter found for handler "FILE"
at org.jboss.logmanager.config.AbstractPropertyConfiguration.setPropertyValueExpression(AbstractPropertyConfiguration.java:194) [jboss-logmanager-2.1.10.Final.jar:2.1.10.Final]
at org.jboss.logmanager.config.AbstractPropertyConfiguration.setPropertyValueString(AbstractPropertyConfiguration.java:155) [jboss-logmanager-2.1.10.Final.jar:2.1.10.Final]
at org.apache.activemq.artemis.core.server.LoggingConfigurationUpdater.configureProperties(LoggingConfigurationUpdater.java:351) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.LoggingConfigurationUpdater.configureHandler(LoggingConfigurationUpdater.java:323) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.LoggingConfigurationUpdater.configureHandlerNames(LoggingConfigurationUpdater.java:363) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.LoggingConfigurationUpdater.configureLogger(LoggingConfigurationUpdater.java:193) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.LoggingConfigurationUpdater.configure(LoggingConfigurationUpdater.java:111) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.LoggingConfigurationUpdater.configure(LoggingConfigurationUpdater.java:85) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.LoggingConfigurationFileReloader.reload(LoggingConfigurationFileReloader.java:46) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.reload.ReloadManagerImpl$ReloadRegistry.check(ReloadManagerImpl.java:124) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.reload.ReloadManagerImpl.tick(ReloadManagerImpl.java:67) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.reload.ReloadManagerImpl.run(ReloadManagerImpl.java:48) [artemis-server-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForExecutor(ActiveMQScheduledComponent.java:313) [artemis-commons-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.lambda$bookedRunForScheduler$2(ActiveMQScheduledComponent.java:320) [artemis-commons-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.17.0.jar:2.17.0]
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) [artemis-commons-2.17.0.jar:2.17.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_191]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_191]
at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.17.0.jar:2.17.0]
may be i need to check the source code.
It was the default logging.properties which i used
# Root logger option
loggers=org.eclipse.jetty,org.jboss.logging,org.apache.activemq.artemis.core.server,org.apache.activemq.artemis.utils,org.apache.activemq.artemis.utils.critical,org.apache.activemq.artemis.journal,org.apache.activemq.artemis.jms.server,org.apache.activemq.artemis.integration.bootstrap,org.apache.activemq.audit.base,org.apache.activemq.audit.message,org.apache.activemq.audit.resource
# Root logger level
logger.level=INFO
# ActiveMQ Artemis logger levels
logger.org.apache.activemq.artemis.core.server.level=INFO
logger.org.apache.activemq.artemis.journal.level=INFO
logger.org.apache.activemq.artemis.utils.level=INFO
# if you have issues with CriticalAnalyzer, setting this as TRACE would give you extra troubleshooting information.
# but do not use it regularly as it would incur in some extra CPU usage for this diagnostic.
logger.org.apache.activemq.artemis.utils.critical.level=INFO
logger.org.apache.activemq.artemis.jms.level=INFO
logger.org.apache.activemq.artemis.integration.bootstrap.level=INFO
logger.org.eclipse.jetty.level=WARN
# Root logger handlers
logger.handlers=FILE,CONSOLE
# to enable audit change the level to INFO
logger.org.apache.activemq.audit.base.level=ERROR
logger.org.apache.activemq.audit.base.handlers=AUDIT_FILE
logger.org.apache.activemq.audit.base.useParentHandlers=false
logger.org.apache.activemq.audit.resource.level=ERROR
logger.org.apache.activemq.audit.resource.handlers=AUDIT_FILE
logger.org.apache.activemq.audit.resource.useParentHandlers=false
logger.org.apache.activemq.audit.message.level=ERROR
logger.org.apache.activemq.audit.message.handlers=AUDIT_FILE
logger.org.apache.activemq.audit.message.useParentHandlers=false
# Console handler configuration
handler.CONSOLE=org.jboss.logmanager.handlers.ConsoleHandler
handler.CONSOLE.properties=autoFlush
handler.CONSOLE.level=DEBUG
handler.CONSOLE.autoFlush=true
handler.CONSOLE.formatter=PATTERN
# File handler configuration
handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
handler.FILE.level=DEBUG
handler.FILE.properties=suffix,append,autoFlush,fileName,rotateSize,maxBackupIndex,rotateOnBoot
handler.FILE.suffix=.yyyy-MM-dd-HH-mm
handler.FILE.append=true
handler.FILE.autoFlush=true
handler.FILE.fileName=${artemis.instance}/log/artemis.log
handler.FILE.formatter=PATTERN
## Added for Log rotate
handler.FILE.rotateSize=25600
handler.FILE.maxBackupIndex=3
handler.FILE.rotateOnBoot=true
# Formatter pattern configuration
formatter.PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.PATTERN.properties=pattern
formatter.PATTERN.pattern=%d %-5p [%c] %s%E%n
#Audit logger
handler.AUDIT_FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
handler.AUDIT_FILE.level=INFO
handler.AUDIT_FILE.properties=suffix,append,autoFlush,fileName,
handler.AUDIT_FILE.suffix=.yyyy-MM-dd
handler.AUDIT_FILE.append=true
handler.AUDIT_FILE.autoFlush=true
handler.AUDIT_FILE.fileName=${artemis.instance}/log/audit.log
handler.AUDIT_FILE.formatter=AUDIT_PATTERN
formatter.AUDIT_PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.AUDIT_PATTERN.properties=pattern
formatter.AUDIT_PATTERN.pattern=%d [AUDIT](%t) %s%E%n
There's a handful of problems with your configuration.
If you want to use both time & size based rotation you need to use org.jboss.logmanager.handlers.PeriodicSizeRotatingFileHandler. Currently you're using org.jboss.logmanager.handlers.PeriodicRotatingFileHandler which will only rotate based on time.
You're formatting your rotation config properties incorrectly. You're using - characters when you should be using camel case like the rest of the properties. I believe this is because you're reading the documentation from JBoss EAP which has a slightly different configuration format than the plain properties-based configuration used by ActiveMQ Artemis.
You aren't specifying the rotation config properties in the properties configuration for the FILE handler.
You're using the size notation k which isn't supported in the plain properties-based configuration used by ActiveMQ Artemis.
Try using this instead:
handler.FILE=org.jboss.logmanager.handlers.PeriodicSizeRotatingFileHandler
handler.FILE.level=DEBUG
handler.FILE.properties=suffix,append,autoFlush,fileName,rotateSize,maxBackupIndex,rotateOnBoot
handler.FILE.suffix=.yyyy-MM-dd-HH-mm
handler.FILE.append=true
handler.FILE.autoFlush=true
handler.FILE.fileName=${artemis.instance}/log/artemis.log
handler.FILE.formatter=PATTERN
handler.FILE.rotateSize=25600
handler.FILE.maxBackupIndex=3
handler.FILE.rotateOnBoot=true
Related
How do I setup logging.properties to log diverts in artemis.log?
I understand that TRACE should be used for org.apache.activemq.artemis.core.server.impl.DivertImpl
How do I set it up in etc/logging.properties?
To enable a particular logger (e.g. org.apache.activemq.artemis.core.server.impl.DivertImpl) in logging.properties you must first add the logger to the loggers list at the top of the file. Here is the default loggers list with org.apache.activemq.artemis.core.server.impl.DivertImpl added:
loggers=org.eclipse.jetty,org.jboss.logging,org.apache.activemq.artemis.core.server,org.apache.activemq.artemis.utils,org.apache.activemq.artemis.journal,org.apache.activemq.artemis.jms.server,org.apache.activemq.artemis.integration.bootstrap,org.apache.activemq.audit.base,org.apache.activemq.audit.message,org.apache.activemq.audit.resource,org.apache.activemq.artemis.core.server.impl.DivertImpl
Then you need to configure the logging level for the logger to TRACE, e.g.:
logger.org.apache.activemq.artemis.core.server.impl.DivertImpl.level=TRACE
Lastly, you need to update the level of the necessary handler to allow the TRACE logging through, e.g.:
handler.CONSOLE.level=TRACE
or
handler.FILE.level=TRACE
My logs are getting hammered by below log message in JBOSS 7. Can you anyone suggest how to stop this log message.
2018-02-28 13:37:13,618 WARN [com.arjuna.ats.arjuna] (default-threads - 48) ARJUNA012141: Multiple last resources have been added to the current transaction. This is transactionally unsafe and should not be relied upon. Current resource is LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl#5d70439b[connectionListener=653eac5d connectionManager=7f6856e8 warned=false currentXid=null productName=MySQL productVersion=10.2.13-MariaDB-log jndiName=java:/jdbc/db_jndi]))
In your standalone.xml file, in the logging section, add something like this under the appropriate handler element:
<filter>
<not>
<match pattern="ARJUNA012141"/>
</not>
</filter>
Of course, you should add these lines using the jboss-cli utility. Did you know that changes to logging don't require a server restart, but will be picked up at the defined refresh interval?
I am using log4j-gwt aud gwt's remote logging. I get the messages logged on my console as expected but did not managed to get the message print on my physical .log file.
Any idea of how I can do this?
Here is my log4j properties file (which works fine for all non-gwt related messages):
# CONSOLE APPENDER CONFIG [common] ---------------------------------------------------------------
log4j.appender.CONSOLE_APPENDER=org.apache.log4j.ConsoleAppender
#log4j.appender.CONSOLE_APPENDER.layout=org.apache.log4j.SimpleLayout
log4j.appender.CONSOLE_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE_APPENDER.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
# ROOT LOGGER CONFIG ----------------------------------------------------------------------
log4j.rootLogger=DEBUG,ROOT_FILE_APPENDER
log4j.appender.ROOT_FILE_APPENDER=org.apache.log4j.RollingFileAppender
log4j.appender.ROOT_FILE_APPENDER.File=C:/log/tbps_root.log
log4j.appender.ROOT_FILE_APPENDER.MaxFileSize=20480KB
log4j.appender.ROOT_FILE_APPENDER.MaxBackupIndex=5
log4j.appender.ROOT_FILE_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.ROOT_FILE_APPENDER.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
# GWT -------------------------------------------------------------------------------------
#These are various unseccsful attemps...
log4j.logger.com.google.gwt.logging.server.RemoteLoggingServiceUtil=DEBUG,ROOT_FILE_APPENDER
log4j.logger.com.google.gwt.logging.server.RemoteServiceServlet=DEBUG,ROOT_FILE_APPENDER
log4j.logger.com.google.gwt.logging.server.simpleRemoteHandler=DEBUG,ROOT_FILE_APPENDER
log4j.logger.com.google.gwt.logging=DEBUG,ROOT_FILE_APPENDER
log4j.logger.com.google.gwt.logging.Logging=DEBUG,ROOT_FILE_APPENDER
log4j.logger.com.google.gwt.logging.server=DEBUG,ROOT_FILE_APPENDER
GWT-log4j and GWT's RemoteLoggingService use different loggers, as described here. Hence, your log4j properties are not being applied to GWT's remote logger.
You can either implement your own remote logging class, or use slf4j to "bridge" the two loggers.
I recently added logs of the user's actions to a GWT application. I first tried using GWT-log4j in conjunction with RemoteLoggingService and had this same issue. After reading the above link I created my own logger class -- this was particularly nice as I could pass data objects to the remote logger allowing me to serialize the state of the GWT application. This later became very useful :)
I'm running a GWT app in a dev mode with a custom Jetty container. The app loads fine for the first time, however, if I refresh it, I get the following errors in the Development Mode window (paths changed):
00:16:44.854 [ERROR] Unable to create file 'C:\somePath\src\war\msjavaSnack\C4EA130FD0ED44BE513FEEDDE13614DA.cache.png'
java.io.FileNotFoundException: C:\somePath\src\war\msjavaSnack\C4EA130FD0ED44BE513FEEDDE13614DA.cache.png (The requested operation cannot be performed on a file with a user-mapped section open)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
at com.google.gwt.core.ext.linker.impl.StandardLinkerContext.writeArtifactToFile(StandardLinkerContext.java:658)
at com.google.gwt.core.ext.linker.impl.StandardLinkerContext.produceOutputDirectory(StandardLinkerContext.java:595)
at com.google.gwt.dev.DevMode.produceOutput(DevMode.java:476)
at com.google.gwt.dev.DevModeBase.relink(DevModeBase.java:1131)
at com.google.gwt.dev.DevModeBase.access$000(DevModeBase.java:67)
at com.google.gwt.dev.DevModeBase$2.accept(DevModeBase.java:1076)
at com.google.gwt.dev.shell.ShellModuleSpaceHost$1.accept(ShellModuleSpaceHost.java:122)
at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:59)
at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:154)
at com.google.gwt.dev.shell.ShellModuleSpaceHost.rebind(ShellModuleSpaceHost.java:119)
at com.google.gwt.dev.shell.ModuleSpace.rebind(ModuleSpace.java:531)
at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:414)
at com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:39)
at com.google.gwt.core.client.GWT.create(GWT.java:98)
at com.extjs.gxt.ui.client.GXT.<clinit>(GXT.java:38)
at com.extjs.gxt.ui.client.widget.Component.<clinit>(Component.java:202)
at msjava.snack.gui.client.MSHeaderPanelViewport.<init>(MSHeaderPanelViewport.java:62)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:422)
at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:361)
at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:185)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:380)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:222)
at java.lang.Thread.run(Thread.java:662)
UPDATE
In the ProcessExplorer I can see that the JVM process hosting Jetty has an open handle to the file so this is probably the reason why the other JVM (hosting the dev mode) can't write to it. Any way to work it around?
It seems that two (open/close) (open/close) rutines over the same file happening too soon one after another causes this... Some developers suggest to call the gc. Check for closing correctly every i/o operation. Not to perform complete (open,loop(writes),close) too soon. It seems that when one operation it is going to be finished while the second request arrives and that throws the problem.
I found the solution on this page:
http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows
EDIT:
The above URL is dead now.
Now it's quite easy to find the solution in Jetty's wiki:
Jetty provides a configuration switch in the webdefault.xml file for
the DefaultServlet that enables or disables the use of memory-mapped
files. If you are running on Windows and are having file-locking
problems, you should set this switch to disable memory-mapped file
buffers.
The default webdefault.xml file is in the lib/jetty.jar at
org/eclipse/jetty/webapp/webdefault.xml. Extract it to a convenient
disk location and edit it to change useFileMappedBuffer to false.
https://wiki.eclipse.org/Jetty/Howto/Deal_with_Locked_Windows_Files
I've installed the Eclipse (eclipse-SDK-3.6.2-aix-gtk-ppc64.zip) on an AIX instance. Initially it appeared to be starting but buttons would just stop working. I eventually tracked this down to Eclipse throwing the following exception:
JVMDUMP006I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError" - please wait.
JVMDUMP032I JVM requested Snap dump using '/home/atginst/eclipse/Snap.20120309.111040.8650798.0001.trc' in response to an event
JVMDUMP010I Snap dump written to /home/atginst/eclipse/Snap.20120309.111040.8650798.0001.trc
JVMDUMP032I JVM requested Heap dump using '/home/atginst/eclipse/heapdump.20120309.111040.8650798.0002.phd' in response to an event
JVMDUMP010I Heap dump written to /home/atginst/eclipse/heapdump.20120309.111040.8650798.0002.phd
JVMDUMP032I JVM requested Java dump using '/home/atginst/eclipse/javacore.20120309.111040.8650798.0003.txt' in response to an event
JVMDUMP010I Java dump written to /home/atginst/eclipse/javacore.20120309.111040.8650798.0003.txt
JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError".
Exception in thread "[Timer] - Main Queue Handler" java.lang.OutOfMemoryError: native memory exhausted
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:274)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:580)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:550)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:481)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:469)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:457)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:618)
at org.eclipse.equinox.internal.util.ref.Log.getService(Log.java:424)
at org.eclipse.equinox.internal.util.ref.Log.logMessage(Log.java:438)
at org.eclipse.equinox.internal.util.ref.Log.error(Log.java:155)
at org.eclipse.equinox.internal.util.impl.tpt.threadpool.ThreadPoolManagerImpl.getObject(ThreadPoolManagerImpl.java:98)
at org.eclipse.equinox.internal.util.impl.tpt.threadpool.ThreadPoolManagerImpl.execute(ThreadPoolManagerImpl.java:201)
at org.eclipse.equinox.internal.util.impl.tpt.threadpool.ThreadPoolFactoryImpl.execute0(ThreadPoolFactoryImpl.java:112)
at org.eclipse.equinox.internal.util.impl.tpt.timer.TimerImpl.run(TimerImpl.java:110)
at java.lang.Thread.run(Thread.java:736)
I have changed the -Xms and -Xmx values to different settings to no avail. Analyzing the corresponding thread dump shows that 99% of the memory in the VM is available.
Am I missing something obvious in setting this up?
I would try setting the -Xss and -Xmso option to set the internal/OS thread stack size. Its a nonstandard option on IBM's JVM.
After various attempts at editing the eclipse.ini file, the only reliable way I can currently start it with is by passing the -vm parameter in the startup as follow:
./eclipse -vm /Websphere/java/bin/java -vmargs -Xmx1024M &