Sid, can you restate your actual problem from an application perspective? Just list the requirements of what you are trying to achieve.
-----Original Message----- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 10:18 PM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working - Design Suggestion Isn't this one of the intentions of clustering. To do work load and to some degree failover balancing. If you have more than one server where the message are designed to be routed to you solve your problem of scaling. If one of the destination servers goes down you have automatic faliover to the other members of the cluster. Critical supplies can be made durable by implementing replication and clustering from a hardware perspective. Granted MQSeries in it's self is not an out-of-the box solution for all the problems associated with a messaging system. But then again a hammer alone doesn't build a house. At least you have determined the pit falls of your design at an early stage. With some re-thought and pinging ideas off the LISTSERV you will eventually come up with a system that can take a punch or two. Father Bobbee >From: [EMAIL PROTECTED] >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Triggering across New Cluster not working - Design Suggestion >Date: Sat, 8 Nov 2003 08:46:37 +1000 > >Yep, everyone's comments are valid... I re-read the Queue Manger Cluster >manual again last night and found a one liner on the limitation of >MQGET.... >just a single line ( and not a mention in any of the other manuals as far >as >I can see so far). > >I find this a serious limitation for my design. The queue needs some kind >of >flag that says it's available for GETing across the cluster, otherwise you >need to re-design your applications to hunt down the queue. > >I can solve the triggering problem, just trigger locally and have my apps >connect to each server, the real issue is the clients connecting in. > >It does not make sense to me that you can PUT accross the cluster but must >attach locally to the QM to get the data. I now need to do a re-design of >my >client application to obtain it's data. I'm trying to send sensitive >medical >data where a duplication of data could be fatal and with 1000's of >multi-threaded clients coming online in the next 12 months a single server >will not cut it. > >My best solution so far is to have clients connect, discover their queue is >not present (CC=2085), build a Permanent Dynamic queue (or something >similar) and PUT to a Dist list of queues serviced by a data move app to >move the data to the temporary queue. > >Any other design suggestions are more than welcome. > >Sid Young >Brisbane >Australia > > > > > > >-----Original Message----- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Saturday, 8 November 2003 4:38 AM >To: [EMAIL PROTECTED] >Subject: Re: Triggering across New Cluster not working [Deutsche Boerse >Systems: Virus ch > > >Picking up on what Stefan is indicating. one of the requirements for >triggering is that the INIT Q is available and opened for input by some >process (hopefully the Trigger monitor) from the LINUX side can the QMGR >verify this through the cluster if those attributes are true or false??? > > bobbee > >I will say this is an interesting twist to triggering. MAybe you need a >process on LINUX that starts the NT process like secured shell. > > > >From: Stefan Raabe <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Triggering across New Cluster not working [Deutsche Boerse > > Systems: Virus checked] > >Date: Fri, 7 Nov 2003 11:40:55 +0100 > > > >Sid, > > > >i hope i understood your environment right: unix and nt in an mqseries > >cluster, > >local > >queue on unix should be triggerd, initqueue is a cluster queue that is > >local on > >the > >nt system. > > > >triggering is a "local" kind of processing, which means that the >initiation > >queue has to > >be a local queue. triggering will not work when you specify a cluster >queue > >(which is on a different queuemanager in your case) as initiation queue. > > > >as others already stated, there may be a missunderstanding of the cluster > >functionality.... > >making a queue a cluster queue will make it known within the cluster, but > >it is > >not > >the same as if it is defined in every cluster queuemanager. > > > >these 600 other queues are local on the nt system? if yes, thats why the > >triggering on nt works > >for them. if not, please ignore this mail :-) > > > >regards, stefan > >|+----------------+----------------------------------------------------+--- >---| > >|| [EMAIL PROTECTED]| | > >. | > >|| .COM.AU | To: [EMAIL PROTECTED] | > > | > >|| | cc: (bcc: Stefan Raabe/DBS/GDB) | > > | > >|| 07.11.2003 | Subject: Triggering across New | > > | > >|| 02:26 | Cluster not working [Deutsche Boerse Systems: | > > | > >|| Please | Virus checked] | > > | > >|| respond to | | > > | > >|| MQSeries List| | > > | > >|| | | > > | > >|+----------------+----------------------------------------------------+--- >---| > > > > > > > > > > > > > > > > > >Howdy all, > > > >I have just put together a new cluster between two machine (NT4 and >Linux) > > > >The process to run is on the NT machine as well as the trigger monitor >and > >the > >initiation queue that it monitors. I have place a copy of the process > >definition on both machine and the queue with triggering turned on is > >located on > >the linux box. All queues have the cluster defined. > > > >I can see the required queues in the cluster using display qc(*) but >when > >I put > >stuff into that queue (on the linux box) the triggering does not appear >to > >work. > > > >I have 600 other queues still on the NT box which are triggering fine > > > >Any Ideas...Please!!!! > > > > > >Sid Young > >Brisbane > >Australia > > > > > >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 > >_________________________________________________________________ >Frustrated with dial-up? Get high-speed for as low as $26.95. >https://broadband.msn.com (Prices may vary by service area.) > >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 _________________________________________________________________ Crave some Miles Davis or Grateful Dead? Your old favorites are always playing on MSN Radio Plus. Trial month free! http://join.msn.com/?page=offers/premiumradio 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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
