minmanmax


I am trying to use the example in http://support.microsoft.com/kb/915852.  This creates two databases SourceDB and TargetDB.  If I put SourceDB on the same SQL Server instance as TargetDB, the messages is received with no problem.  If I put the SourceDB on another Server so than I am using two separate servers in the same domain, the message never gets to the TargetDB.  I have changed the routes to the correct server names and set the route port to 8286.

CREATE ROUTE [myRoute]

    WITH

    SERVICE_NAME = 'SourceService',

    address = 'TCP://toto:8286';

and:

CREATE ROUTE [myRoute]

    WITH

    SERVICE_NAME = 'TargetService',

    address = 'TCP://devbox05:8286';

 

My SourceDB is on one of several instances on the server toto. My instance is toto\foxylady01,52005.

The certificates were generated using the passwords in the article.




Re: Cant get two servers to connect with certificates kb 915852

MikeTomkies


CREATE ENDPOINT BrokerEndpoint STATE = STARTED AS TCP

(LISTENER_PORT = 8286) FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE ctfname)

select * from sys.service_broker_endpoints

Do you have an endpoint command to create and view to check as above






Re: Cant get two servers to connect with certificates kb 915852

minmanmax

I ran the query you asked on both the Source and the Target.  Both endpoints showed up correctly.  The code to generate the endpoints was the same as you posted. 

If I recreate all databases, endpoint and logins, then create a copy of the source database on the target server and then send the a message from Source to Target on the same server it works.  Then I can send from the Source Server to the Target Server and IT WORKS TOO!!!    But this is true only if I first send a message from Source to Target on the same server first. 

Message command:

USE SourceDB

SET NOCOUNT ON

DECLARE @conversationHandle uniqueidentifier

BEGIN TRANSACTION

          -- Start dialog.

          BEGIN DIALOG  @conversationHandle

          FROM SERVICE    [SourceService]

          TO SERVICE      'TargetService'

          ON CONTRACT     [mycon]

          WITH ENCRYPTION = ON, LIFETIME = 60;

 

          -- Send message.

          SEND ON CONVERSATION @conversationHandle

          MESSAGE TYPE [mymsg] (N'Hi, from '+@@ServerName)

          end conversation @conversationHandle

COMMIT






Re: Cant get two servers to connect with certificates kb 915852

Remus Rusanu

[quote user='minmanmax']

WITH ENCRYPTION = ON, LIFETIME = 60;

If the dialog is begun with a lifetime of 60 (seconds), then is normal to see the lifetime expired messages after one minute. A dialog has to be closed by both endpoints within its lifetime.

HTH,
~ Remus






Re: Cant get two servers to connect with certificates kb 915852

minmanmax

I have removed the trace info from my post because that clouds the isssue.

The issue is this: 

If I recreate both sorce and target databases, endpoint and logins, then create a copy of the source database on the target server and then send the a message from Source to Target on the same server it works.  Then I can send from the Source Server to the Target Server and IT WORKS TOO!!!    But this is true only if I first send a message from SourceDB to TargetDB on the same server first. 

I have looked and found no errors or hanging conversations. all 5 queues are empty on all servers. 

Even after getting the source server to work this way, it stops without and error.  The messages just stop geting to the target.

 

 





Re: Cant get two servers to connect with certificates kb 915852

Remus Rusanu

How do you create a the copy of the database

If I inderstand correctly, you have two machines, say A and B. On A you have a service SA and and on B you have a service SB, as well as a seond instance of the service SA, say SA'.

Whenever you are dealing with multiple copies of the same service, you must take into account the broker instance implications. SSB is able to distiguish two services based on the broker instance. If broker instance is not specified, then the first message sent by the initiatitor will pick at random one of the possible service instances and deliver the message to it. When the first reply comes back, it will carry with it the broker instance and the dialog becomes sticky to this very servic instance (subsequent messages will specify which broker instance they are targeting).
Also, your routes must specify the broker instance explictily, other wise we cannot determine which route is the correct one for a specific service instance. So in the example above:
- on machine A, is enough to specify a route to B for SB
- on machine B, in the SB database you must specify a route with a service instance to SA
- on machine B, in the SB database, specify a LOCAL route fro SA' , with a service instance
-
the AutoCreateLocal route in SA' database is sufficient for SA' to reach SB

When SA or SA' begins a dialog with SB, then things should work w/o any problem.
When SB begins a dialog with "SA" w/o specifying a broker instance, then both SA and SA' are valid targets and one will be randomly picked
When SB whant to determine explicitly if it wants to talk with SA or SA', it needs to specify the broker instance in BEGIN DIALOG.
If SB never needs to talk with SA' but only with SA, then the route to SA' has to be dropped, including the AutoCreatedLocal route that exposes it automatically becaus eit is on the same SQL Instance.

HTH,
~ Remus






Re: Cant get two servers to connect with certificates kb 915852

minmanmax

It was my Vista Firewall. I opened the port in my firewall described in the CREATE ROUTE statement and it works now. The very scary thing is that it worked intermittently as described above.

After I solved the other trace errors from the MSDN example I was left with the destination server trace showing nothing and this error from source server trace:

Connection attempt failed with error: '10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)'.