Has anyone here ever seen the message "Waiting to connect" on outgoing queues when using queued components? We have an application that was written in part with queued components. Both the Application server and MSMQ server are on clusters. The COM+ proxy exports for the queued components has been run on the application server. Now, when a message is sent to a queued component, it remains in the outgoing queue on the application server and the outgoing queue state says that it is either "Waiting to connect" or "Inactive". Any thoughts on this? - Jeff Marler B-)
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Queued Component Waiting To Connect
- Thread starter jmarler
- Start date
- Thread starter
- #3
Thanks for answering Chip . . .
All of the components were written in VB 6.0 running on WIN2k Pro Servers. The overall load at the time was very light ( 4-5 users). This error only seems to happen when we are running on the cluster boxes. When we break the MSMQ cluster into a single MSMQ box, it seems to work fine . . . any thoughts? - Jeff Marler B-)
All of the components were written in VB 6.0 running on WIN2k Pro Servers. The overall load at the time was very light ( 4-5 users). This error only seems to happen when we are running on the cluster boxes. When we break the MSMQ cluster into a single MSMQ box, it seems to work fine . . . any thoughts? - Jeff Marler B-)
Hmmm.
I haven't used MSMQ on a cluster, but I recall that when running MS SQLServer, you supply a "virtual" address for the server, one that works no matter which member of the cluster is "up" at the moment. Would the same thing apply with MSMQ? Using a virtual GUID for the Queue Name rather than a specific GUID for the servers?
Your load is pretty light, so the usual VB6 serialized access problem on COM+ shouldn't be an issue.
How is authentication being done? I was using NT 4, so we just had your typical SQL-based authentication and domain-level sign-ons, but if you're running 2000 Advanced Server, I'm pretty sure you have to be using Active Directory.
You've probably already written a small test app that just posts a message, and another that reads a message from the Queue?
Chip H.
I haven't used MSMQ on a cluster, but I recall that when running MS SQLServer, you supply a "virtual" address for the server, one that works no matter which member of the cluster is "up" at the moment. Would the same thing apply with MSMQ? Using a virtual GUID for the Queue Name rather than a specific GUID for the servers?
Your load is pretty light, so the usual VB6 serialized access problem on COM+ shouldn't be an issue.
How is authentication being done? I was using NT 4, so we just had your typical SQL-based authentication and domain-level sign-ons, but if you're running 2000 Advanced Server, I'm pretty sure you have to be using Active Directory.
You've probably already written a small test app that just posts a message, and another that reads a message from the Queue?
Chip H.
- Status
Similar threads
- Locked
- Question