...
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE MNG-1003 : ting down : RMI Registgry : Listening on port 8999 2009-07-09 15:50:20 +0100 MESSAGE MNG-1003 : ting down : RMI ConnectorServer : Listening on port 9099 2009-07-09 15:50:20 +0100 MESSAGE MNG-1005 : Stopped |
VirtualHost
Virtualhosts cannot be programatically created so the log messages will have to be found during the startup/shutdown of the broker.
Startup
During startup the following VHT message will be logged as the Virtualhost is created and its working directory specified.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] VHT-1001 : Created : <name> 2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] VHT-1002 : Work directory : <path> |
Shutdown
On shutdown the Virutalhost will only log that it has been closed.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] VHT-1003 : Closed
|
MessageStore
The MessageStore details will be logged as part of the Virtualhost startup and shutdown.
Startup
Aside from the easy to test create(MST-1001) and store location(MST-1002) messages, a persistent store such as DerbyDB will also need to be used in testing so that the recovery messagse MST-1004-6 can be tested.
It is expected that on recovery start MST-1004 will be logged without a queue name. Then as each queue is recovered then a start(MST-1004), count (MST-1005) and Complete (MST-1006) will be logged. Only when all queues have been recovered will a final complete (MST-1006) be logged.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-1001 : Created : <name> 2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-1002 : Store location : <path> 2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-1003 : Closed : <name> 2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-1004 : Recovery Start \[: <queue.name>] 2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-1005 : Recovered <count> messages for queue <queue.name> 2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-1006 : Recovery Complete \[: <queue.name>] |
Shutdown
On shutdown the MessageStore will only log that it has been closed.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ vh:(<name>) ] MST-10071003 : Closed |
Connection
New connections can be easily performed in isolation by connecting to the running broker. The connection open and close log messagse should be presented in response to the new connection and the closure of the connection.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/) ] CON-1001 : Open : Client ID <id> : Protocol Version : <version> 2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/) ] CON-1002 : Close |
Channel
As with connection creation Channel creation can be tested in isolation. Whilst a channel will be created along with the connection. A new channel can be created from the Java client by creating a new JMS Session. The current Java client will start all Channels on the JMS Connections flowed. This means that an intial 'CHN-1002 : Flow Stopped' message will be logged. Only when the JMS Connection is started will the Channel bun unflowed and a 'CHN-1002 : Flow Started' logged.
Additional testing should be done to ensure that CHN-1002 messages are logged when the client exceeds its prefetch count and the broker flows the client.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2 ] CHN-1001 : Create : Prefetch <count> 2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2 ] CHN-1002 : FlowedFlow <value> 2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2 ] CHN-1003 : Close |
Queue
There are a number of properties that can be set on a Queue and as a reusult they all need to be tested in isolation and validated that the correct log message is generated based on this template:
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2/qu(myqueue) ] QUE-1001 : Create : [AutoDelete] [Durable|Transient] [Priority:<levels>] [Owner:<name>] |
Property combinations to test:
- Durable | Transient
- AutoDelete
- Priority
This results in 6 tests as each Combination of AutoDelete|Priority|None is tested against Durable|Transient.
A simple deleted is logged when the queue is finaly deleted.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2/qu(myqueue) ] QUE-1002 : CloseDeleted |
Exchange
As with Queue logging the Exchange has the Durable option that must be tested indpendently. During broker startup the default exchanges will be created and so will be logged. Testing should ensure that these log messages are indeed correctly logged.
However as Exchanges can be programatically declared this should also be tested.
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2/ex(amq.direct) ] EXH-1001 : Create : [Durable] Type:<value> Name:<value> 2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2/ex(amq.direct) ] EXH-1002 : CloseDeleted |
Binding
No Format |
---|
2009-07-09 15:50:20 +0100 MESSAGE [ con:1(guest@127.0.0.1/)/ch:2/ex(amq.direct)/qu(myQueue)/rk(myQueue) ] BND-1001 : Create [: Arguments : <key=value>] 2009-07-09 15:50:20 +0100 [ con:1(guest@127.0.0.1/)/ch:2/ex(amq.direct)/qu(myQueue)/rk(myQueue) ] MESSAGE BND-1002 : Close |
...