We were under XA at the time and it was not causing us an issue. How may retries does it take to establish the connection. We were running a job in CRON to query the DB and restart the queue. I believe the timing on that was at a 10 or 15 min interval. Maybe that was giving the Broker enough time to reestablish the connection.
I didn't say it was not supported. I just said from an infrastructure idea I would advise against it. It's your boat. What ever floats it!!! o -;
bee-oh-dubble-bee-dubble-egh
From: "Kulbir S. Thind" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: WBIMB Broker restart without Broker restart Date: Tue, 16 Nov 2004 18:44:46 +0000
What we're not seeing is the connection handle re-establish after the first message is caught as an exception, the subsequent messages also error. May be this is because of the XA configuration we have put in place.
Also, in terms of sharing the database for broker and application usage this was run past IBM and is documented in there manuals as something that is supported. We also wanted to avoid dedicating an entire Oracle database just for the brokers use.
Cheers.
"Robert Broderick" <[EMAIL PROTECTED]>
Sent by: "MQSeries List" <[EMAIL PROTECTED]> 16-Nov-2004 18:05 Please respond to "MQSeries List" <[EMAIL PROTECTED]>
To: MQSERIES
cc: Subject: Re: WBIMB Broker restart without Broker restart
You are going to get two different exception thrown. (at least as of 2.1, I have not verified if this is the case on 5.0). The first on is that the database is not available. The second is that the connection handle is invalid.
When the database is taken offline the flow reacts with the DB not available. When the DB comes back online the first attempt to access the database fails with a message that the current handle is not valid (something like that). At this point you reprocess the message and all should work ok. What we did, if memory serves me right was to turn write a message to a queue and throw an exception in the CATCH connection that caught the DB error and place the message back on the queue. The message that was written triggered a queue that shut down the flow. We had a script that ran every so often that would query the DB. If it was online it would check the queue and it it was "GET DISABLED" it would reenable it so processing could start again. Simple and it worked.
OH BTW....if you are using the Broker or Configuration Manager DB for an application dbatabase STOP IT or you will go blind!!!!!
FRom a pure operations standpoint. the Broker and Configuration amanger DB's are infrastructure databases. Application should not be allowed to store data in these databases. They are used for subscriptions and aggregation besides the normal broker stuff. These DB's are under the ownership of the IBM WBI suite of applications. You risk infrastruction issues with WBIMB and possibly your application by keeping application data there. (just my two thoughts!!)
bobbee
>From: "Kulbir S. Thind" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: WBIMB Broker restart without Broker restart >Date: Tue, 16 Nov 2004 16:38:39 +0000 > >Hi, > >In a scenario where the WBIMB broker database is restarted without the >WBIMB broker being restarted we find that flows throw exceptions when >processing messages as the connection handle for the database is not >valid. Eventually, however the broker manages to re-establish connection >with the broker and continue processing as normal. > >Ideally we should be re-starting the broker if the underlying database is >restarted, however for various reasons we want to be able to handle the >scenario above. Is there a way of tuning WBIMB so that it refreshes its >connection handles more regularly? > >Also, please note that the database used serves two purposes, its the >broker internal database and the database used by the message flows for >lookups, etc. > >TIA, > >Kulbir.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
