[developers] store and forward (continued..)

Tue, 22 May 2001 07:11:02 -0700

Title: RE: [developers] store and forward (continued..)
Ok, so the static routes are between routers, not between the router and the producer.
That make much more sense. Sound like what I want to for high availability.
 
so the config :
 
swiftlet.sys$routing.staticroute.routers.names=router1,router2,router3
 
sets static routes from
1 -> 2
1 -> 3
2 -> 1
2 -> 3
3 -> 1
3 -> 2
 
correct?
-----Original Message-----
From: Brian Duke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 22, 2001 9:22 AM
To: [EMAIL PROTECTED]
Subject: [developers] store and forward (continued..)

No, you have to be able to connect to a router. What I was referring to was when you have routers connected to each other on different machines. In this case you can create a static route in your local router to a queue on a remote router. Then you can connect to your local router and send messages to the queue on the remote router and if the local router is not currently connected to the remote router, it will hold the message until the connection becomes available, and then forward it on. Does that help?
 
- Brian
-----Original Message-----
From: Vago, John N [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 22, 2001 10:15 AM
To: [EMAIL PROTECTED]
Subject: [developers] store and forward (continued..)

Just read the online docs about static routes, and have a question.
Do they allow  a 'client-side queue' for when a producer can't connect to the router?
Does the router have to be up, but not the connection?

I'm trying to design some failover for my persistant queues, which as I understand
are attached to a router. So I can't have myqueue@router1 AND myqueue@router2.

Anyway, static routes read like that my producer sending to myqueue@router1 will 'queue'
up messages even if router1 is down, untill it comes back. Then all messages will
be delivered.

Confused...

Thanks,
John

> -----Original Message-----
> From: Brian Duke [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 8:55 AM
> To: [EMAIL PROTECTED]
> Subject: [developers] store and forward (continued..)
>
>
> You beat me to it Gregor. This is exactly what we're doing to ensure
> messages get to where they need to go even when the
> connection is down.
> Works great!
>
> -----Original Message-----
> From: Gregor Kovač [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 3:19 AM
> To: [EMAIL PROTECTED]
> Subject: [developers] store and forward (continued..)
>
>
> Hi!
>
> In SwifMQ if you know that routers are going to get invisible
> to each other
> it is good to define a static routes between them. That way
> you will not
> get those errors.
> I haven't used this, but I see in the API docs that you can create a
> TopicSession that is transacted and thus you can use transactions with
> topics.
>
> Hope this helps.
> Best regards,
>          Kovi
>
>
> At 08:21 22.5.01 +0200, you wrote:
> >Hi all,
> >I am facing the same situation as someone else mentioned
> before. Having
> >used MQSeries, I am familiar with the concept of a 'remote
> queue', which,
> >in  SwiftMQ parlance, is a queue in say router1 which
> 'represents' a queue
> >(say testqueue2) in router2. So if you connect to router1 and send a
> >message to that queue, it succeeds even if router2 is down
> at the time.
> >The message stays in the remote queue, and gets forwarded.
> >On the other hand, the send fails, with a 'No Such Queue' error.
> >Just to confirm, is that feature getting any consideration of being
> >implemented?
> >Someone suggested to use Topics instead. But receiving
> messages from a
> >Topic can not be done under transactional control (tell me
> if i am wrong).
> >So, my question is, can SwiftMQ be used a robust,
> transactional messaging
> >solution across an unreliable network (by which i mean
> routers can become
> >invisible to eachother occasionally).
> >thanks,
> >Manjuka
> >_____________________________________________________________
> ______________
> >Visit http://www.visto.com/info, your free web-based
> communications center.
> >Visto.com. Life on the Dot.
> >
> >
> >------------------------------------------------------
> >SwiftMQ developers mailing list * http://www.swiftmq.com
> >To unsubscribe from this list, send an eMail to
> >[EMAIL PROTECTED] and write in the body of your message:
> >UNSUBSCRIBE developers <your-email-address>
> >Archive: http://www.mail-archive.com/developers@mail.iit.de/
>
>
> ------------------------------------------------------
> SwiftMQ developers mailing list * http://www.swiftmq.com
> To unsubscribe from this list, send an eMail to
> [EMAIL PROTECTED] and write in the body of your message:
> UNSUBSCRIBE developers <your-email-address>
> Archive: http://www.mail-archive.com/developers@mail.iit.de/
>
>
> ------------------------------------------------------
> SwiftMQ developers mailing list * http://www.swiftmq.com
> To unsubscribe from this list, send an eMail to
> [EMAIL PROTECTED] and write in the body of your message:
> UNSUBSCRIBE developers <your-email-address>
> Archive: http://www.mail-archive.com/developers@mail.iit.de/
>
>
>
> 

------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to 
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers 
Archive: http://www.mail-archive.com/developers@mail.iit.de/




------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to 
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers 
Archive: http://www.mail-archive.com/developers@mail.iit.de/





------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to 
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers 
Archive: http://www.mail-archive.com/developers@mail.iit.de/

Reply via email to