MQ config.properties log level bug

[z-mathe]

Hi,

After migrating our remote enhanced (HA) broker cluster from Open MQ 4.5.2 Patch 1 (in Glassfish 3.1.2) to MQ 5.1.1 (in Payara 172), we experienced, that the log file (\mq\instances[instance-name]\log\log.txt) is full of INFO level messages too, even though there is a line imq.log.level=WARNING in the config.properties (\props\ folder, originated from previous configuration).

But if we query the broker properties, the running level value is INFO:

imqcmd query bkr -b host:port ... ... Log Level       INFO Log Rollover Interval (seconds) Log Rollover Size (bytes) Successfully queried the broker.

The same config with MQ 4.5.2 results the WARNING as running value. Reading the documentation (https://javaee.github.io/openmq/Documentation.html), we tried the above config.properties settings, but running level left INFO too:

imq.broker.log.level=WARNING imq.log.file.output=WARNING|ERROR

If we start the Payara with embedded MQ, the dynamically created config.properties (under \imq\ folder) template same as the older version's (e.g. MQ 4.x) configuration tepmplate (not just for logging settings).

The only one workaround is the imqbrokerd.exe -loglevel WARNING command line parameter (because this option overrides the default INFO running level).

Environment

• Payara Version: 4.1.2.172
• Edition: Full
• JDK Version: 8 u131 - Oracle
• Operating System: Windows
• Database: SQL Server

[fturizo]

@z-mathe, before trying to reproduce the issue. How are you configuring the broker cluster on your environment? How are you referencing the JMS host configuration on your Payara installation?

[z-mathe]

Hi Fabio,

Sorry, the MQ broker cluster environment is absolutely independent from Payara domain configuration, you dont need to start appserver for reproducing (practically REMOTE type, but we still use parallel inprocess EMBEDDED configuartion in Payara to achieve the "useSharedSubscriptionInClusteredContainer" feature for topic subscriptions and lookup from code to the not configured remote instances, so the embedded instances not in use, but this is a long story, it is not related to this case).

imqbroker start command (modified with loglevel parameter as workaround) on 2 server nodes: \bin\imqbrokerd.exe -silent -force -name instance_x -vmargs "some_mem_args" -loglevel WARNING

\mq\etc\imqenv.conf (original +java home): IMQ_DEFAULT_JAVAHOME=C:/Program Files/Java/jdk1.8.0_131

\mq\instances\instance_x\props\config.properties (with many cluster, port and MSSQL server jdbc persistence parameters, and with the ineffective log level option): imq.log.level=WARNING

[z-mathe]

The cluster properties (although I do not think this is important):

imq.cluster.heartbeat.hostname={hostname}
imq.cluster.port=47678
imq.cluster.heartbeat.port=47681
imq.cluster.monitor.threshold=20
imq.cluster.monitor.interval=5
imq.cluster.ha=true
imq.cluster.clusterid=backend_MQ
imq.cluster.nomasterbroker=true
imq.cluster.heartbeat.threshold=2
imq.cluster.heartbeat.interval=10

[smillidge]

Is this reproducible on a newly installed Payara environment?

[z-mathe]

I will try it with a v174 on this week. OK?

[z-mathe]

Reproduction steps:

• unzip Payara download (v174 or v181, each has MQ5.1.1)
• in cmd window, goto \mq\bin folder and start broker process initially with imqbrokerd.exe without parameters (I'm under windows)
• Stop this process (double Ctrl+C)
• Go to the newly created /var/instances/imqbroker/props folder (initally no explicit varhome defined in \etc\imqenv.conf) and add "imq.log.level=WARNING" new line to the end of the defaultly created config.properties file (in the comment block, there is instruction for this property)
• Start the broker process secondly with imqbrokerd.exe (even now without any parameters)
• Start a new cmd window and query the broker props: imqcmd.exe query bkr (with the default admin/admin account) -> the output in the cmd window resulted: Log Level: INFO

I tried even now with GF 3.1.2 (MQ4.5.2), and the above scenario resulting: Log Level: WARNING.

[smillidge]

So this is an issue with an OpenMQ external broker rather than Payara Server?

[z-mathe]

Yes, so I suppose this announcement should be made for OpenMQ developers (https://javaee.github.io/openmq/). :(

[smillidge]

We provide support for OpenMQ to customers as it is part of Payara Server. However the code with the issue isn't in this GitHub repo. The OpenMQ code has migrated to the Eclipse Foundation as part of the migration to JakartaEE. You can raise the issue on their repo https://github.com/eclipse-ee4j/openmq the Payara team have a committer on that project as well.