| Author |
Message
|
| rparti |
 Posted: Mon Nov 19, 2007 3:52 pm Post subject: Server Requestor with triggering |
 |
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
I have configured a triggered Sender/Receiver Channel. The intercommunication manual mentions that I can also trigger a server channel in the same way as the sender channel.
Is it possible to trigger a server-requestor channel? I doubt it considering that the transmission queue is on the server side, but the session is initiated by the requestor. How would the requestor know that data is available on the server, to initaite the session in the first place.
Please clarify |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Nov 19, 2007 4:46 pm Post subject: |
|
|
Guest
|
Channel ends that start with the letter "s" - server and sender - are the channel ends where the MCA looks into a transmission queue for messages to send, and sends them across the network.
The "r" channel ends - receiver and requester - channel end MCAs take messages off the network, and put them into destination queues.
The term "server" in a server-requester channel pair means that one end (the server) is unattended - nobody there to issue the start channel command. So, something needs to start the channel. In a server-requester channel pair, somebody or something (automation) issues the start channel at the requester channel end, then "hangs up" and waits for the server to re-initiate the channel start process. |
|
| Back to top |
|
|
| rparti |
| Posted: Mon Nov 19, 2007 5:03 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| bruce2359 wrote: |
So, something needs to start the channel. In a server-requester channel pair, somebody or something (automation) issues the start channel at the requester channel end, then "hangs up" and waits for the server to re-initiate the channel start process. |
The requestor end is not associated with a transmission queue as you rightly stated. What can be the something (automation) since triggering channels are associated with transmission queues which are on the server end.
The question again was Can the requestor-server channel be configured as a triggered channel? If so, please explain how? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Nov 19, 2007 5:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQSC.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rparti |
| Posted: Mon Nov 19, 2007 5:22 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| Reading the manuals, I dont think it is possible. My explainations are provided above. Please clarify |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 19, 2007 5:25 pm Post subject: |
|
|
Guest
|
| Quote: |
| Can the requestor-server channel be configured as a triggered channel? |
MQ channel triggering is based on a server or sender end transmission queue being triggered. So, yes at the server end; no at the requester end.
But, yes at the requester end if you have some kind of automation (a Windows service, cron, Tivoli, etc.) to initiate the channel start. In this case, the 'triggering' is based on an event - usually a non-MQ event. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Nov 19, 2007 5:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The requester channel connects to the Listener on the sending qmgr. It then negotiates with the listener to start the server. All this is accomplished from starting the requester.
You can use MQSC to start a requester channel.
You can then do something to 'automate' that.
There isn't any part of the product, that I'm aware of, that will magically notify one queue manager (the one holding the requester channel) that there are messages waiting on some other random queue manager (the server channel side).
The entire point of requester channels is that the requesting side decides when to start the channel. This is done without knowledge of whether there are messages or not.
If you want the sending side to start the channel, use a receiver, not a requester. It's that simple.
Or do something ridiculous like create a client trigger monitor to the sending qmgr, and have it run a script to start the requester on the receiving qmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rparti |
| Posted: Mon Nov 19, 2007 5:42 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
Thanks for the reply Jeff. I was just trying to clarify my thoughts and I'd like to imagine that we were thinking on the same lines ;oD
The solution I came up with was to start the channel manually and set the disconnect interval to 0, so it never stops.
I could not think of any way to 'automate' the requestor side.
However I will try to investigate other solutions instead of svr-rqstr. I cant use a sdr-rcvr because the sdr side would be a client who do not have permission to initiate a session. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 19, 2007 6:04 pm Post subject: |
|
|
Guest
|
| Quote: |
| The solution I came up with was to start the channel manually and set the disconnect interval to 0, so it never stops. |
If the channel fails, you will have to start it manually again, and again, and ...
| Quote: |
| I could not think of any way to 'automate' the requestor side. |
You could write an application program that runs on the requester end qmgr that MQINQuires on the requester channel, and issue the start command if necessary. If UNIX, you could cron every minute to issue the start command. If it's already running (or otherwise active) no harm, no foul (fowl?). |
|
| Back to top |
|
|
| rparti |
| Posted: Mon Nov 19, 2007 6:29 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| Thank you Bruce. This looks like a good way to automate. Will definately give it a try |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 19, 2007 8:03 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I don't understand what you are trying to accomplish. You want to automate the startup of a Server/Requester channel from the receiving side. Why? When? Based on what conditions?
Bruce wrote:
| Quote: |
| You could write an application program that runs on the requester end qmgr that MQINQuires on the requester channel, and issue the start command if necessary. If UNIX, you could cron every minute to issue the start command. If it's already running (or otherwise active) no harm, no foul (fowl?). |
And you liked that. But its pointless to issue start commands once a minute with no thought process. If you are going to do that you might as well just start up the channel once with DISCINT 0 and let it run.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 19, 2007 8:25 pm Post subject: |
|
|
Guest
|
A requester-server channel pair satisfies the unattended servers' need to have the channel start in order to send messages to the requester end. With this channel pair, either end may start the channel.
From the Intercomm manual:
Requester-server channel
A requester in one system starts the channel so that it can receive messages from the other system. The requester requests the server at the other end of the channel to start. The server sends messages to the requester from the transmission queue defined in its channel definition.
A server channel can also initiate the communication and send messages to a requester, but this applies only to fully qualified servers, that is server channels that have the connection name of the partner specified in the channel definition. A fully qualified server can either be started by a requester, or can initiate a communication with a requester. |
|
| Back to top |
|
|
| rparti |
| Posted: Mon Nov 19, 2007 8:39 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| PeterPotkay wrote: |
I don't understand what you are trying to accomplish. You want to automate the startup of a Server/Requester channel from the receiving side. Why? When? Based on what conditions?
|
Well, the objective was to have a triggered channel, so when data was available to send, no manual intervention to start channels would ever be required.
This is however not possible with a svr-rqstr as with a sdr-rcvr.(see discussion above)
A disconnect interval of 0 would always keep the channel active. However I have seen that the channel could once in a blue moon not be running.
Do you have any suggestions? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 19, 2007 9:26 pm Post subject: |
|
|
Guest
|
| Quote: |
| Well, the objective was to have a triggered channel, so when data was available to send, no manual intervention to start channels would ever be required. |
That's not what your original post said. You wanted a requester-server channel to be started from the requester end. Any server or sender channel can be started by setting the xmit queue to trigger the channel to start. This satisfies your objective - as stated above.
What else? Be more specific, please. |
|
| Back to top |
|
|
| rparti |
| Posted: Tue Nov 20, 2007 12:50 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
Bruce, I apologize if I caused any confusion.
To summarize, I know how the svr-rqstr and sdr-rcvr work. However I was wondering if the svr-rqstr can be in a trigger channel setup as a sdr-rcvr can be.
We have a client that sends data to us. However they do not have authority to initiate a session (because of firewall rules in place). So we chose to use the svr-rqstr, with client being server.
I want to be able to use a disconnect interval with the channels so they are not in running state when there is no data. I want to use triggered channel so when data is available to send, the channel can start up automatically.
However I could not find a way to implement svr-rqstr in a triggered channel setup.
If anyone knows, please advise. Personally I don't believe it is possible. Hence I thought of using the setup with a disconnect interval of 0.
I have also found that sometimes the disconnet interval of 0 still might require manual intervention to start the channel. Hence I was looking to automate the start of channel if it stops by any chance |
|
| Back to top |
|
|
|
|
