| Author |
Message
|
| dwitherspoon |
 Posted: Tue May 24, 2005 12:29 pm Post subject: Publisher acts ok even though MessageBroker is down |
 |
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
I'm doing some unit testing on my code and have seen something weird.
I bring up my app, and he builds a connection to a queue mgr and a TopicPublisher. All is well, cuz everything is up.
Then, I take the MessageBroker down on the server, and get my app to publish. I expect it to fail...but it doesn't. No exception is thrown. I can do this all day.
Then, I have a little test app I wrote to fling messages around (handy for testing), and I try to publish. It fails, finding that that MessageBroker won't respond.
So then I stop my app, and restart him. He now fails to start, finding that he can't publish an initial message cuz the MessageBroker is down.
So it's like if the MB goes away after you built a TopicPub, you'll never hear about it.
What's up with that?
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue May 24, 2005 12:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Are you looking into ExceptionListeners and such ?
 |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue May 24, 2005 12:40 pm Post subject: |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
The publish call is wrapped in a try block, catching JMSException.
This is the same code that catches the problem during initialization, so I feel confident that it works.
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 24, 2005 1:10 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| dwitherspoon wrote: |
The publish call is wrapped in a try block, catching JMSException.
This is the same code that catches the problem during initialization, so I feel confident that it works. |
I think fjb_saper is telling you that your code won't see an exception unless you implement an ExceptionListener.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 24, 2005 1:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
More specifically I want him to check out the possibilities.
Using the try-catch block is nice but it will not notify if for any reason the broker goes down as the message will go to the broker queue and for a point to point everything looks fine.
Now a TopicConnection might not be the same animal as a queue Connection and if the broker specified in the Topic factory goes down additional errors might be thrown. As Jeff said there is no guarantee that those would be picked up in the try-catch bloc but I hope that an ExceptionListener on the TopicConnection could pick something up there.
Enjoy |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue May 24, 2005 1:33 pm Post subject: |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
OK...I've added an ExceptionListener, but he never gets called. The publish call goes through without a hitch, even though the broker is down.
My understanding is that an EL is for async notification of errors. Since I'm doing a sync publish, I wouldn't expect it to fire.
I'm trying one more thing, but I'm not picking up a trail here...
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue May 24, 2005 1:57 pm Post subject: |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
Well, I tried my other thing - I had specifically turned of MQ tracing and logging in my app - but that had no effect.
I am running CSD08...tried to download CSD10, but the DownloadDirector thingy cannot connect, so I cannot get it.
Any other ideas?
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 24, 2005 4:14 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Are there messages piling up on the broker input queue?
It may be that the TopicConnection only requires feedback from the broker when it starts up - and is fully capable of publishing messages while the broker is down.
I would expect the publications to be processed when the broker started up again, if this is the case.
And I'd consider it a positive feature - so I could perform maintenance on my broker or load-balance/fail it over without having to restart my app servers.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dwitherspoon |
| Posted: Tue May 24, 2005 4:21 pm Post subject: |
|
|
Acolyte
Joined: 09 Dec 2003
Posts: 59
|
What's that broker queue name? I know it's just queues underneath the pub/sub stuff, but I've never dived (dove?) in deep enough to know what the actual queues are.
_________________
Good...Fast...Cheap. Choose any two. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue May 24, 2005 6:54 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
I don't have my WMQ system with me, but I believe that publishes go to SYSTEM.DEFAULT.BROKER.STREAM (or something with stream in it). Other command messages go to SYSTEM.CONTROL.BROKER.QUEUE (or something similar).
And I think jeff may have hit the nail on the head. I thought that I remember reading somewhere about an option to wait for broker notification of acceptance or not. I just can't remember where..... |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed May 25, 2005 6:21 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
The actual queue names are:
SYSTEM.BROKER.CONTROL.QUEUE
SYSTEM.BROKER.DEFAULT.STREAM
In the 'Messages sent to the broker' section of the Publish/Subscribe manual, it has the following:
| Quote: |
MsgType
Can be set to MQMT_REQUEST for a command message if a response is always required. The MQRO_PAN and MQRO_NAN flags in the Report field are not significant in this case.
Can be set to MQMT_DATAGRAM, in which case responses depend on the setting of the MQRO_PAN and MQRO_NAN flags in the Report field:
- MQRO_PAN alone means that the broker is to send a response only if the command succeeds.
- MQRO_NAN alone means that the broker is to send a response only if the command fails.
- If a command succeeds partially a response is sent if either MQRO_PAN or MQRO_NAN is set.
- MQRO_PAN + MQRO_NAN means that the broker is to send a response whether the command succeeds or fails. This has the same effect from the broker’s perspective as setting MsgType to MQMT_REQUEST.
- If neither MQRO_PAN nor MQRO_NAN is set, no response will ever be sent. |
You might want to look at your publish message since it may not be working and you may have indicated that you don't want to know about a failure. |
|
| Back to top |
|
|
| malammik |
| Posted: Wed May 25, 2005 6:58 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
|
| Back to top |
|
|
|
|
