Error resolving party

Topics: Developer Forum, Project Management Forum, User Forum
May 2, 2008 at 9:26 AM
Edited May 2, 2008 at 9:37 AM
Hi all,

I have implemented a BizTalk solution with 5 parties which communicate with each other over the TCPIP adapter.
The party gets resolved using the IPAddress as described in the manual and it normally works perfectly but
sometimes a problem appears.

The problem that I have is that sometimes the adapter will say it can not resolve the party and will stop sending
messages to that party. I haven't been able to find the problem yet and would be very happy if someone could
help me to solve the issue. I can say that the IPAddress of the parties does not get changed nor the physical
connection get broken.

The error in the event viewer is:
"A message sent to adapter "TCPIP Adapter" on send port "Party1_TCPOut" with URI "TCP://Party1" is suspended.
Error details: 30.04.2008 13:53:14.937:146: The duplex worker thread TcpSendDuplexWorkerThread146
failed to resolve the duplex address against the BizTalk Party Party1. The message to be transmitted
will be suspended. The exception thrown is: The duplex address was not found for the BizTalk Party
Party1 in the BizTalk Management database."

Thanks for any help.

Mario.
Coordinator
May 7, 2008 at 11:13 PM
The adapter uses the standard DNS resolution so usually this means that the address could not be validated.
Do you usually have to recycle the host instance to get things working again ?
May 10, 2008 at 7:39 AM

Hi,

I can restart the host instance and it will work (I don't normaly do this as it interrupts all other processes :-) )
or I can stop/start the send port and receive location involved in the problem and it works as well (preferred "solution").

This is making me many troubles as even with all retry options activated messages stay hanging on the BTServer as
once the error comes it does not recover even when all client systems are online and pingable.

Regards,
Mario


jplummer wrote:
The adapter uses the standard DNS resolution so usually this means that the address could not be validated.
Do you usually have to recycle the host instance to get things working again ?



May 10, 2008 at 9:10 AM
Edited May 10, 2008 at 9:12 AM
  .
Coordinator
May 13, 2008 at 10:43 PM

The Method below is where this is generated which is called from the DuplexworkerThread
Clearly the code found a party called Party1 so it looks like the SendPort BizTalkPartyAliasName and BizTalkPartyAliasQualifierDuplexAddress values for the work item do not appear to mact whats being returned from the BizTalkMgmtDb.

        /// <summary>
        ///     This method retrieves the duplex listener address from the BizTalk Party.  If the BizTalk Party doesn't exist, it throws
        ///     a BizTalkPartyNotFoundException or if the address doesn't exist, it throws a DuplexAddressNotFoundException exception.
        /// </summary>
        private string GetDuplexAddress(string bizTalkPartyName)
        {
            // Get catalog object
            BtsCatalogExplorer catalog = new BtsCatalogExplorer();
            catalog.ConnectionString = SendAdapter.BizTalkManagementDatabaseConnectionString;

            // Get party
            Party bizTalkParty = catalog.Parties[bizTalkPartyName];

            if (bizTalkParty == null)
            {
                // Not found
                throw new BizTalkPartyNotFoundException(bizTalkPartyName);
            }

            // Find the duplex address
            string duplexAddress = string.Empty;
            foreach (PartyAlias alias in bizTalkParty.Aliases)
            {
                if (alias.Name == SendLocation.BizTalkPartyAliasName &&
                    alias.Qualifier == SendLocation.BizTalkPartyAliasQualifierDuplexAddress)
                {
                    duplexAddress = alias.Value;
                    break;
                }
            }

            if (duplexAddress == string.Empty)
            {
                // Not found
                throw new DuplexAddressNotFoundException(bizTalkPartyName);
            }

            // Return address found
            return (duplexAddress);
        }

May 14, 2008 at 5:49 AM
Hi,
thank you for the answer. It seems that I may have some sort of unstability on the network that causes
the connection to break down sometimes (even when I can't find any traces of it) and the messages that
are processed in that same moment will not be delivered. I will try to find the problem and if it is related
to BT I will post the info to help those who may have the same problem

Best regards,
Mario.
May 19, 2008 at 8:06 AM
Hi!

I have been investigating the whole problem and have noticed two situations:
 
1. Sometimes if the connection gets lost and then tried to be restablished, the TCPAdapter
    accepts the connection again but does not bind it to the sendport (the DuplexAddress
    item is not to be found under the Party properties), thus not being able to find the
    party.

2. If the connection gets lost and then tried to be restablished, the TCPAdapter blocks
    the port and the client gets the error "Can not connect to endpoint as the destination
    computer rejects the connection."

Hope you can help me to solve this problems as this is the only problem of my application.

Best regards,
Mario.
Coordinator
May 20, 2008 at 8:49 PM
Hi Mario

1. So is this the connection getting dropped from your sending (client) app or are you saying that BTS is dropping the connection ?
2. Understood.

I guess looking at some of the W2K3 tcpip parameters may be worth looking at (KeepAlive and such like) http://technet2.microsoft.com/windowsserver/en/library/295d391e-6efd-4499-8c14-80b6ef75124e1033.mspx?mfr=true
I'm tied up in aproject at the moment and will try to have a look at this soon.

John
May 21, 2008 at 2:36 PM
Well, the problem with the DuplexAddres described in my previous message is true for both cases.
If I look in the log files of the client, sometimes it does not even appear as if the connection would have
been broken. That's the reason why I assume it lies on BT or the Adapter.

Thx,
Mario.




jplummer wrote:
Hi Mario

1. So is this the connection getting dropped from your sending (client) app or are you saying that BTS is dropping the connection ?
2. Understood.

I guess looking at some of the W2K3 tcpip parameters may be worth looking at (KeepAlive and such like) http://technet2.microsoft.com/windowsserver/en/library/295d391e-6efd-4499-8c14-80b6ef75124e1033.mspx?mfr=true
I'm tied up in aproject at the moment and will try to have a look at this soon.

John


Jun 5, 2008 at 8:44 AM

Hi John,

I have further information of the error that I'm having. This are the log entries logged just before getting the "Party can not be resolved" error.
By the time that the error comes the connection was already restablished by the client "Party1".

05.06.2008 07:08:13.163: 40: A general socket error has occurred.  The exception message associated with the error is: The given host is unknown.

The receive location "Party1_TCPIP" with URL "TCP://SERVERNAME:9001" is shutting down. Details:"The given host is unknown".

05.06.2008 07:08:13.194: 43: A receive location with address TCP://SERVERNAME:9001 has been removed from the TCP receive adapter.

05.06.2008 08:28:32.819:204: ReceiveInitialiseNewBatch: New Batch Initialised in WorkerThread TcpRecvBatchWorkerThread204

05.06.2008 08:28:38.491:172: The duplex worker thread TcpSendDuplexWorkerThread172 failed to resolve the duplex address against the BizTalk Party Party1.  The message to be transmitted will be suspended.  The exception thrown is: The duplex address was not found for the BizTalk Party Party1 in the BizTalk Management database.

I hope you can help me with this one as everyone is getting nervous with the fact that we don't get the stability that we should have.
I know you are very bussy but anyway hope you can get a minute or two to take a look at it.

Thanks in advance.
Mario.

Nov 12, 2008 at 5:57 PM
Mario,
Did you ever find the resolution to this issue?  I'm experiencing the same thing.
Nov 25, 2008 at 9:57 AM
Hi,

I did not resolve the issue...

I tried to achieve some more stability on the physical network and increased the reconnect interval on
the clients so that the previous duplex connection dies before trying to reconnect.

This did not solve the problem completely as it still shows up from time to time but it is a bit better now.

I whish I could give you a better news :(

Regards,
Mario.