I get bunch of messages like these:
2018-09-25 14:22:42.606 [DEBUG] akka.actor.LocalActorRefProvider(akka://cluster) - Resolve (deserialization) of path [system/ddataReplicator/$b#1795511840] doesn't match an active actor. It has probably been stopped, using deadLetters.
2018-09-25 14:22:42.607 [DEBUG] akka.actor.LocalActorRefProvider(akka://cluster) - Resolve (deserialization) of path [system/ddataReplicator/$a#161990085] doesn't match an active actor. It has probably been stopped, using deadLetters.
2018-09-25 14:22:48.897 [DEBUG] akka.actor.LocalActorRefProvider(akka://cluster) - Resolve (deserialization) of path [system/ddataReplicator/$b#1795511840] doesn't match an active actor. It has probably been stopped, using deadLetters.
2018-09-25 14:22:48.898 [DEBUG] akka.actor.LocalActorRefProvider(akka://cluster) - Resolve (deserialization) of path [system/ddataReplicator/$a#161990085] doesn't match an active actor. It has probably been stopped, using deadLetters.
which I would like not to log at debug level. Afaik I cannot just use logger name akka.actor.LocalActorRefProvider because the full logger name includes cluster name (akka.actor.LocalActorRefProvider(akka://cluster)), and we name those differently based on environment it is run, so something like this won't work:
<logger name="akka.actor.LocalActorRefProvider" level="info" />
One option as I understand would be to use regex filters:
Which works, but I'm not sure if this is optimal?
Solved by adding:
<logger name="akka.actor.LocalActorRefProvider(akka://${sys:logging.clustername})" level="info" />
And then passing the logging.clustername at runtime with :
-Dlogging.clustername=current-cluster-name
Related
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
I am working on configuring NLog configuration which works perfectly for logging into text files. Now on the top of this I want to set a conditional target as Mail which should get fired only for a specific set of exceptions. For example - if there is a PaymentFailedException, CardExpiredException then the NLog should target Mail.
I have checked the NLog documentation but I could not find any way to set it for specific set of exceptions. However, NLog allows for setting target as Mail for exception levels.
You could configure use the <when> for this.
e.g.
<logger name="*" writeTo="myMailTarget">
<filters>
<when condition="not contains('${exception:format=type}', 'PaymentFailedException") action="Ignore" />
</filters>
</logger>
See filtering log messages and <when> docs
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 Msmqdistributor service of Enterprise Library 3.1 to distribute logs from various application.I have defined multiple listeners in categorySources/specialSources, but if one listener is failed than subsequent listeners will be never executed.
Following is my config code.
<specialSources>
<allEvents switchValue="Warning" name="All Events">
<listeners>
<add name="Database Listener A" />
<add name="Custom Trace Listener A" />
<add name="Custom Trace Listener B" />
</listeners>
</allEvents>
<notProcessed switchValue="Warning" name="Unprocessed Category" />
<errors switchValue="Warning" name="Logging Errors & Warnings"/>
</specialSources>
If I am specifying wrong connection string for Database Listener A then it will be failed to insert logs in database. But it also stops the jobs of next Custom Trace Listener A and Custom Trace Listener B.So here Custom Trace Listener A and Custom Trace Listener B will be never executed if Database Listener A is failed.
Anybody can help please ?
Thanks
Mitesh Patel
This behavior seems to be "by design". See the answer for Microsoft Enterprise Library 4.1 Logging Fails on Windows XP SP3.
Of course, this doesn't really help you. One workaround would be to attach one listener to a category. So for your 3 listeners you could add 3 categories. This will work but is not particularly elegant.
Since you indicate that you are using 2 custom trace listeners another approach to mitigate the issue would be to code the custom trace listeners to swallow any exceptions (not usually a good idea, though). You could also order your trace listeners from least likely to fail to most likely to fail. E.g. Database > Event Log > Flat File. In your scenario place the custom trace listeners before the database trace listener.
It is also good practice to add a trace listener to the errors category. Not sure if you have that in your app or not (but the posted config doesn't).
I am trying to configure my message endpoint mapping in my NServiceBus configuration by sending messages from different namespaces to different endpoints.
As such, I have configured the following in my web.config:
<MessageEndpointMappings>
<add Messages="Company.Messages.Accounts" Endpoint="ServiceInput" />
<add Messages="Company.Messages.Payments" Endpoint="ServiceInput" />
<add Messages="Company.Messages.Cancellations" Endpoint="ServiceInput" />
<add Messages="Company.Messages.Notifications" Endpoint="ServiceInput" />
</MessageEndpointMappings>
However, when my application starts, I receive the following exception:
Spring.Objects.PropertyAccessExceptionsException: PropertyAccessExceptionsException (1 errors); nested PropertyAccessExceptions are:
[Spring.Core.TypeMismatchException: Cannot convert property value of type [System.Collections.Hashtable] to required type [System.Collections.IDictionary] for property 'MessageOwners'., Inner Exception: System.ArgumentException: Problem loading message assembly: Company.Messages.Payments ---> System.IO.FileNotFoundException: Could not load file or assembly 'Company.Messages.Payments' or one of its dependencies. The system cannot find the file specified.
File name: 'Company.Messages.Payments'
What I find interesting is that it seems to have found Company.Messages.Accounts but failed on the second configured line. I thought that maybe it didn't like have them all go to the same endpoint, but changing this configuration to have them go different endpoints didn't change the error message I received.
What am I doing wrong? Is it not possible to segment messages by namespace (all I have seen is by type and by assembly)?
Thanks,
Steve
NSB only supports mapping of assemblies or individual types to endpoints. Namespaces are not supported, I suggest you split you message assembly into separate assemblies for each of your endpoints.
According to this page you can specify a type:
http://docs.particular.net/nservicebus/messaging/message-owner
Specific types can be configured by using their qualified name: "namespace.type, assembly".
As of NServiceBus v3.3 namespaces can be used to filter message mappings
http://docs.particular.net/nservicebus/messaging/message-owner