This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Operational Logging - Status Update - Functional Specification
Skip to end of metadata
Go to start of metadata

Functional Specification

This page documents the functional specification for the status updates improvement to the Java Broker.

Log Messages

This is the list of initial status messages that the broker will be configured to produce at for status logging.
These messages will be parameterised as shown and will be accesed via an interface so that we need only maintain the text in a single location. While the messages here do no show These standarised messages will also allow for easy internationalisation.
Each section includes the expected full format of a log message. So taking the Broker logging as an example an entry in the log file for the startup of a 0.6 release broker would be:

2009-07-09 15:50:20 +0100 MESSAGE BRK-1001 : Startup : Version 0.6 Build: exported

The expected format is shown at the start of each section in italics. This is then followed by the list of messages that can be logged. This formating (as fully defined here) is the reason that each log message that follows does not need to contain a lot of details. For example, when logging the creation of a Channel you would want to know more details than just the prefetch count hence when the message is logged it would look like this:

2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@ ] CHN-1001 : Create : Prefetch 400

BRK-1001 : Startup : Version: <Version> Build: <Build>
BRK-1002 : Starting : Listening on <Transport> port <Port>
BRK-1003 : Shuting down : <Transport> port <Port>
BRK-1004 : Ready
BRK-1005 : Stopped
BRK-1006 : Using configuration : <path>
BRK-1007 : Using logging configuration : <path>

MNG-1001 : Startup
MNG-1002 : Starting : <service> : Listening on port <Port>
MNG-1003 : Shuting down : <service> : port <Port>
MNG-1004 : Ready
MNG-1005 : Stopped
MNG-1006 : Using SSL Keystore : <path>

<DATETIME> MESSAGE [ vh:(<name>) ] <Message>
VHT-1001 : Created : <name>
VHT-1002 : Closed

<DATETIME> MESSAGE [ vh:(<name>) ] <Message>
MST-1001 : Created : <name>
MST-1002 : Store location : <path>
MST-1003 : Closed
MST-1004 : Recovery Start [: <>]
MST-1005 : Recovered <count> messages for queue <>
MST-1006 : Recovery Complete [: <>]

<DATETIME> MESSAGE [ con:1(guest@ ] <Message>
CON-1001 : Open : Client ID <id> : Protocol Version : <version>
CON-1002 : Close

<DATETIME> MESSAGE [ con:1(guest@ ] <Message>
CHN-1001 : Create : Prefetch <count>
CHN-1002 : Flow <value>
CHN-1003 : Close

<DATETIME> MESSAGE [ con:1(guest@ ] <Message>
QUE-1001 : Create : [AutoDelete] [Durable|Transient] [Priority:<levels>] Owner:<name>
QUE-1002 : Deleted

<DATETIME> MESSAGE [ con:1(guest@ ] <Message>
EXH-1001 : Create : [Durable] Type:<value> Name:<value>
EXH-1002 : Deleted

<DATETIME> MESSAGE [ con:1(guest@ ] <Message>
BND-1001 : Create [: Arguments : <key=value>]
BND-1002 : Deleted

<DATETIME> MESSAGE [ con:1(guest@ ] <Message>
SUB-1001 : Create : [Durable] [Arguments : <key=value>]
SUB-1002 : Close








MC has two ports one for RMI Registry, one for RMI ConnectorServer

I've parameterized startup/shutdown to take a service value. So I'd expect two entries in the log for our current MC



MC IDs are not unique


  • No labels

1 Comment

  1. Since the JMX management requires using 2 ports, should they not both be listed? Although console users only need to know the main port, the other can be considered required knowledge, eg for allowing access through a firewall.

    Also, there are some duplicate message ID values in the ManagementConsole section.