[GLASSFISH-18828] The error message shouldn't be output when update the broker by excuting "%GF_HOME%\mq\bin\imqcmd update bkr -o imq.system.max_size=100b" successfully Created: 22/Jun/12  Updated: 20/Dec/16  Resolved: 01/Jul/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_dev
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Jeremy_Lv Assignee: David Zhao
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows XP

Attachments: Java Source File DestinationManagerConfig.java    
Issue Links:
depends on MQ-306 Deal with error messages when excutin... Open


[Bug Description]
The error message shouldn't be output when update the broker by excuting "%GF_HOME%\mq\bin\imqcmd update bkr -o imq.system.max_size=100b" successfully

1、Setting the mq property by executing "%GF_HOME%\mq\bin\imqbrokerd -Dimq.system.max_size=100m" in an
admin-console called "console1". There's no error messages output in console1
Note:%GF_HOME% is Glassfish v4 Install Directory.

2、After executing "%GF_HOME%\mq\bin\imqcmd update bkr -o imq.system.max_size=100b" in another admin-console
called "console2" successfully, the following error message output in console1.

IMQ: ERROR: DestinationManagerConfig?: cannot parse internal value of MaxTotalMsgBytes?: java.lang.NumberFormatException?: For input string: "100b"
IMQ: WARNING: DestinationManagerConfig?: Problem encountered while getting attribute MaxTotalMsgBytes?:
java.lang.NumberFormatException?: For input string: "100m":
java.lang.NumberFormatException?: For input string: "100m"
IMQ: ERROR: DestinationManagerConfig? notification jmx.attribute.change: encountered problem while getting old
value of attribute MaxTotalMsgBytes?: javax.management.MBeanException

[My Suggestion]
when excuting "%GF_HOME%\mq\bin\imqcmd update bkr -o imq.system.max_size=100b" successfully in
a console, the error message shouldn't be output in another admin-console.

[Affected versions ]
1 4.0_b41
2 gf's trunk until 2012/06/22

Comment by Jeremy_Lv [ 22/Jun/12 ]

This issue is occurred in glassfish v4.0_b41,however, it's related to the component of mq.
The revised the code as follows:

[Source Directory]

Index: mq-broker\broker-core\src\main\java\com\sun\messaging\jmq\jmsserver\management\mbeans\MessageManagerConfig.java
@@ -478,5 +478,6 @@

{ - l = new Long(s); + SizeString ss = new SizeString(s); + l = new Long(ss.getBytes()); }

catch (Exception e)

{ handleGetterException( @@ -764,9 +765,10 @@ }

else if (name.equals("imq.system.max_size")) {

{ - newVal = Long.valueOf(value); + SizeString ss = new SizeString(value); + newVal = new Long(ss.getBytes()); }

catch (NumberFormatException nfe) {

[Revised Version]

I have uploaded my revised java file to the attachment.

Comment by Nigel Deakin [ 15/Feb/13 ]

Logging this as an exception in the broker log is fine. The reporter describes this as "another admin-console", but this is simply the broker log and is a perfectly appropriate place to log the error.

So the only question is whether this error should additionally be reported back to the imqadmin command.

In this particular case a NumberFormatException is detected in the broker in DestinationManagerConfig.update, in the block of code that handles name.equals("imq.system.max_size"). This catches the NumberFormatException and logs it in the broker log. However it doesn't pass any error back to the client.

Note that this problem isn't limited to this particular property: there are lots of other places where exceptions are caught when handling updates to broker properties, and none of them are reported back to the client.

One way to report the error back to the client would to simply rethrow the NumberFormatException. This will be caught in adminDataHandler.handle. It will cause a stack trace to be logged in the broker log, which is unnecessary here, so we should do better than this.

A better possibility would be to throw a more specific exception up to UpdateBrokerPropsHandler.handle, which can then explicitly configure an appropriate reply message.

Note however that any change must apply to all failures logged in this handler, not the specific failure reported here.

Comment by Nigel Deakin [ 15/Feb/13 ]

In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly.

Comment by David Zhao [ 06/Jun/13 ]

Created MQ-306 for tracking.

Generated at Sun Feb 19 21:13:54 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.