April 22, 2016 at 10:13 am
I am seeing this error every few minutes in sql error log
04/20/2016 17:06:01,Logon,Unknown,Service Broker login attempt by user 'domain\serviceuser.' failed with error: 'A previously existing connection with the same peer was detected during connection handshake. This connection lost the arbitration and it will be closed. All traffic will be redirected to the previously existing connection. This is an informational message only. No user action is required. State 80.'. [CLIENT: 192.168.50.74]
The environment is a four node WSFC with three SQL Server 2012 SP3 enterprise instances. Under normal circumstances the SQL server roles run on distinct cluster nodes. The physical cluster nodes have IP addresses 192.168.50.71 - 74 and the WSFC network resources have IP addresses 192.68.50.81 - 83. Each instance is configured to use a static port 50101 - 50103
On each instance service broker is sending messages to another instance. I see the above error in the SQL error log for all of the instances. Each service broker endpoint is configured to listen on all IPs and has port 4022 configured. The routes addresses are configured as TCP://SQLClusterResourceName:4022.
I made some profiler traces and saw a couple of other errors like "This message could not be delivered because it is duplicate" and
"An error occurred while receiving data: '64(The specified network name is no longer available.)" occurring occasionally.
I'm new to service broker, the initial configuration was done by somebody else, but from doing a lot of web searches it seems that the ACK may not being received by the initiator which cause the message to be resent which is why it's a duplicate, as mentioned here
I found this old post which sounds very similar but unfortunately there's no reolution there.
I have tried using the FQDN of the SQL cluster resource in the SB route and forcing the listener to the IP address of the cluster resource instead of all. I also suspected a network issue but have found no other symptoms to support that. I have tried disabling some of the more exotic NIC features, TCP offload, RSS etc. Nothing I tried has made the slightest difference so far.
One thing that surprises me is that the client specified in the error message sometimes has the IP address of the physical cluster node and sometimes the SQL cluster resource IP address, the instances are definitely only listening on the cluster resource IP address, but the service broker can send using either. Is that correct? Is there a way to force all SQL communication to only send on the virtual server IP?
Can anyone help? Where should I go from here?
Viewing 0 posts
You must be logged in to reply to this topic. Login to reply