| Author |
Message
|
| fjb_saper |
 Posted: Wed May 16, 2007 7:39 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
Point 1) It does not work that way.
If you are looking for your MDB to pick up messages from the cluster you need one MDB on each physical (queue local) to read the messages off of it.
You only benefit from the cluster on put.
Point 2)
The general Oracle documentation about JMS will instruct you on how to install the Oracle JMS provider...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| George Carey |
| Posted: Thu May 17, 2007 7:10 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Please see the post by marcin.kasinski
Here it is .. I was trying to get absolute clarification as I had my doubts as well, but Marcin answered in the the affirmative that the MDB into MQ cloud would work ... seee the dialogue below:
| Quote: |
marcin.kasinski
master
Joined: 21 Dec 2004
Posts: 384
Location: Poland / Warsaw
Posted: Tue May 15, 2007 12:40 pm Post subject: Re: MDBs and MQ client connections
--------------------------------------------------------------------------------
| Quote: |
George Carey wrote:
Ok, just to make sure I am understanding you correctly. If I have server A with Oracle app server running on it and an MDB running/listening inside this Oracle app server and this MDB is configured to be listening for messages landing on a queue named QB and QB is available via a MQ Client Connection over on Sever B this will work.
By work I mean messages put on QB by applications on B will have them read by the MDB bean on server A via the On Message() method and pass them into application logic running in app server on server A?
Correct !!! |
Yes
_________________
Marcin |
How do I decide who is correct?!
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 17, 2007 8:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
By understanding the answers better.
In fact, they're both correct.
A client connection points to a specific queue manager. That queue manager is then "local" to the client, regardless of how far away the machine hosting the qmgr is from the machine hosting the client app.
An MQ application - ANY mq application - can only GET messages from queues that are QLOCAL on the queue manager that the application is connected to. Whether or not the connection is a client or server connection, whether or not the app is an MDB or a C app, doesn't matter.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Thu May 17, 2007 9:58 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
Sorry George Carey
I thought you would like me to confirm that both options are correct.
As jefflowrey said think about MDB listener as just simple MQ application framework which lets you write code easier.
With standard MQ application you can connect in bindings mode to local QMGR or client mode to remote QMGR.
In the same way you can configure MDB listener to connect in bindings or client mode.
_________________
Marcin |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu May 17, 2007 3:36 pm Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
I guess in the stream of dialogue the original question can be lost. But the response by Saper starting off with:
| Quote: |
Point 1) It does not work that way.
..... |
_________________
I took this 'IT' as referring back to my original question about MDB behavior.
So I thought Saper meant that an MDB couldn't access the remote queue in client mode which is what marcin said 'IT' could.
I see now,instead, that Saper (I think) was trying to clarify the behavior of an application connected to a queue manager and its ability to only be able to read from the connected-to queue manager.
This is something I have known from the early 90's, when I first started using MQSeries so I thought he was being nice about clarifiying something else but it was on a tangent from my original question. I know that an MQ cluster functionality is only relevant to Puts which is why I asked the earlier question about CLIENTCONN tables, so that if one qmgr failed a rollover to next qmgr in CLIENTCONN table is possible, so I could read from another queue on a running qmgr that I was again client connected to with my MDB.
This is something that was intimated as being functionally possible with WSMQ V6. and JMS by you Jeff but I am not sure yet if or how it would work with MDBs.
So in summary I believe the answer to my original question is still "YES" as Marcin said and that is to restate:
'that an MDB can connect to an MQ qmgr in either local 'BINDING' mode or in 'CLIENT' connection mode meaning as an MQ client using a SVRCONN channel for its connection to the qmgr.
regards,
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 17, 2007 5:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| George Carey wrote: |
This is something I have known from the early 90's, when I first started using MQSeries so I thought he was being nice about clarifiying something else but it was on a tangent from my original question. I know that an MQ cluster functionality is only relevant to Puts which is why I asked the earlier question about CLIENTCONN tables, so that if one qmgr failed a rollover to next qmgr in CLIENTCONN table is possible, so I could read from another queue on a running qmgr that I was again client connected to with my MDB.
This is something that was intimated as being functionally possible with WSMQ V6. and JMS by you Jeff but I am not sure yet if or how it would work with MDBs.
|
You have it right both ways.
If strictly speaking WebSphere MQ, you cannot get on qmgr B what is on a queue local on qmgr A V6 did not change that....
What changes and makes this possible is not WebSphere MQ but WebSphere JMS provider (Part of WAS) with the DB as persistency store.
As your messages are stored in the DB and each appserver accesses the DB and possibly has a JMS Engine you will always find a JMS engine available on the SI Bus and thus access the messages from the central storage (DB)....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri May 18, 2007 8:58 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
What changes and makes this possible is not WebSphere MQ but WebSphere JMS provider (Part of WAS) with the DB as persistency store.
As your messages are stored in the DB and each appserver accesses the DB and possibly has a JMS Engine you will always find a JMS engine available on the SI Bus and thus access the messages from the central storage (DB).... |
Hmm!? This sounds potentially interesting but we are using Oracle App server!
I assume what you are describing is functionality of the messaging engine (part of the SIBus for WAS v6) that is part of the WAS app server. I know nothing about the ME engine in WAS but if it has a database as its 'queue'ing structure and this DB is shared/accessible amongst WAS app servers, I can see what you are saying. Namely that, you can have JMS 'puts' and 'gets' from any app server and any queue that is represented in the database 'of queues'.(if this is what you are saying? and If not, I am confused. )
But in either case again I am talking about Oracle app server which uses 'AQ' as its messaging engine (and by the way it does use Oracle DB as its backing store) but I need to talk to WSMQ for external connectivity.
Ideally the goal is transparency of queue locality for 'gets' and 'puts' but I don't think this exist even between WSMQ and WAS and so this brings me back to the same old WSMQ issues of MQ Client connectivity and qmgr to qmgr fail over capabilities for HA reasons.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri May 18, 2007 9:08 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Sorry this looks to have been a double post of last item -- not sure how?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 18, 2007 5:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
Well you'll always have a single point of failure:
The oracle DB with the AQ queuing
The Oracle MQ/AQ Messaging Gateway (works quite well)...
The connected qmgr(s)
Etc.....
It all depends on the amount of money the organization is willing to spend to fix this... (HA etc...)
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
