|
Home > Archive > BizTalk Server Applications Integration > June 2006 > GNATS Daemon Adapter throwing connection failure errors
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
GNATS Daemon Adapter throwing connection failure errors
|
|
| Farrukh Hassan 2006-06-14, 1:18 pm |
| Hi,
We have built a custom BizTalk 2004 Adapter for GNATS (incident/bug report
request-tracking system which runs on UNIX-like operating systems). We have
used .NET Framwork1.1 TCPClient class to interact with the GNATS daemon to
perform the required operations. For every new port (send/receive) for this
GNATS Adapter we have a separate instance for the Adapter handler class.
Inside the handler instance we maintain a pool of TCPClient connections made
available to deal with multiple simultaneous requests.
Now as we have increased the number of ports (end-points) for this GNATS
Adapter, we are frequently (but not always) getting the following error:
"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"
I wonder if it is a problem with TCPClient connection class, limiting the
number of connections, or it is some restriction on the GNATS Daemon side.
Please comment if anyone of you had resolved a similar problem, or can
provide some tips.
Thanks
Farrukh
p.s. The GNATS daemon connection timeout is already set quite large
(10mins).
| |
| Adrian Hamza [MSFT] 2006-06-15, 1:21 am |
| You said that you have a separate instance of your adapter class for each
new send port and receive location.
How do you map the outgoing message to the instance object associated with
your send port? I am asking this question because the send port
configuration info is given to your adapter through the message being sent.
Basically, I wonder if you create an instance of your adapter class for
each outgoing message since that could exhaust all your TCP ports.
You also said that inside the handler instance you maintain a pool of
TCPClient connections made available to deal with multiple simultaneous
requests. Are these TCPClient connections shared accross your handler
instances? Basically, do you have a single pool of TCPClient connections or
do you have multiple such pools?
Make sure you dispose the objects appropriately (call Dispose/Close methods
if they exist).
You can try to run NETSTAT command on the BizTalk Runtime machine to see if
you are running out of TCP ports.
You can also try to playing with the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Services\Tcpip\Parameters\TcpTim
edWaitDelay registry key. You might consider setting TcpTimedWaitDelay to
30 seconds. This parameter determines the length of time that a connection
will stay in the TIME_WAIT state when being closed. While a connection is
in the TIME_WAIT state, the socket pair cannot be re- used. This is also
known as the "2MSL" state, as by RFC the value should be twice the maximum
segment lifetime on the network. See RFC793 for further details. I believe
the default is 120 seconds, so a socket sits in TIME_WAIT for 2 * 120 = 240
seconds after being closed.
This posting is provided "AS IS" with no warranties, and confers no rights.
Adrian Hamza [MSFT]
http://blogs.msdn.com/ahamza/
My blog on BizTalk 2006
Windows SharePoint Services adapter
--------------------[vbcol=seagreen]
have[vbcol=seagreen]
this[vbcol=seagreen]
made[vbcol=seagreen]
| |
| Adrian Hamza [MSFT] 2006-06-15, 1:21 am |
| You can also take a look at this KB article
http://support.microsoft.com/defaul...kb;EN-US;319502
Beside TcpTimedWaitDelay, another interesting registry key is MaxUserPort.
You can use this registry to increase the number of TCP ports available to
your application.
This posting is provided "AS IS" with no warranties, and confers no rights.
Adrian Hamza [MSFT]
http://blogs.msdn.com/ahamza/
My blog on BizTalk 2006
Windows SharePoint Services adapter
--------------------[vbcol=seagreen]
have[vbcol=seagreen]
this[vbcol=seagreen]
made[vbcol=seagreen]
| |
| Farrukh Hassan 2006-06-15, 1:18 pm |
| Adrian,
Thanks for your kind reply.
There is one instance of the handler for each port configuration, not for
every message.
> How do you map the outgoing message to the instance object associated with
your send port?
We have a layer between the BAF and the actual handler, that manages to
associate messages with the correct handler instance.
> Are these TCPClient connections shared accross your handler instances?
Basically, do you have a single pool of TCPClient connections or do you have
multiple such pools?
For every handler instance there is a separate connection pool.
Whenever, a connection request is made, if there is a 'live' connection
availble in the pool it is returned, or a new connection is created, till
the pool reaches its limit (which is quite rare).
Whenever, the Adapter finishes work on a connection, it only returns it to
the connection pool without calling dispose/close(). So once a tcp
connection is created, it will only be closed when the port is disabled or
BizTalk goes down.
BTW, in the current situation on our production system we have 8 ports (pool
size=10), which means a maximum of 80 connections at a single point. Should
this be a problem with this situation?
Though, I'll try to change the tcp settings and see its effects.
Thanks your help.
Regards,
Farrukh
"Adrian Hamza [MSFT]" <adrianhamza@online.microsoft.com> wrote in message
news:MztnDzBkGHA.2260@TK2MSFTNGXA01.phx.gbl...
> You said that you have a separate instance of your adapter class for each
> new send port and receive location.
> How do you map the outgoing message to the instance object associated with
> your send port? I am asking this question because the send port
> configuration info is given to your adapter through the message being
sent.
> Basically, I wonder if you create an instance of your adapter class for
> each outgoing message since that could exhaust all your TCP ports.
>
> You also said that inside the handler instance you maintain a pool of
> TCPClient connections made available to deal with multiple simultaneous
> requests. Are these TCPClient connections shared accross your handler
> instances? Basically, do you have a single pool of TCPClient connections
or
> do you have multiple such pools?
>
> Make sure you dispose the objects appropriately (call Dispose/Close
methods
> if they exist).
>
> You can try to run NETSTAT command on the BizTalk Runtime machine to see
if
> you are running out of TCP ports.
>
> You can also try to playing with the
>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Services\Tcpip\Parameters\TcpTim[vbc
ol=seagreen]
> edWaitDelay registry key. You might consider setting TcpTimedWaitDelay to
> 30 seconds. This parameter determines the length of time that a[/vbcol]
connection
> will stay in the TIME_WAIT state when being closed. While a connection is
> in the TIME_WAIT state, the socket pair cannot be re- used. This is also
> known as the "2MSL" state, as by RFC the value should be twice the maximum
> segment lifetime on the network. See RFC793 for further details. I
believe
> the default is 120 seconds, so a socket sits in TIME_WAIT for 2 * 120 =
240
> seconds after being closed.
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> Adrian Hamza [MSFT]
> http://blogs.msdn.com/ahamza/
> My blog on BizTalk 2006
> Windows SharePoint Services adapter
>
> --------------------
report[vbcol=seagreen]
> have
to[vbcol=seagreen]
> this
> made
properly[vbcol=seagreen]
the[vbcol=seagreen]
side.[vbcol=seagreen]
>
| |
| Adrian Hamza [MSFT] 2006-06-15, 7:18 pm |
| See snipet below from MSDN. Make sure you are closing/disposing of
NetworkStream objects. Sometimes the error messages are bogus.
TcpClient and TcpListener represent the network using the NetworkStream
class. You use the GetStream method to return the network stream, and then
call the stream's Read and Write methods. The NetworkStream does not own
the protocol classes' underlying socket, so closing it does not affect the
socket.
This posting is provided "AS IS" with no warranties, and confers no rights.
Adrian Hamza [MSFT]
http://blogs.msdn.com/ahamza/
My blog on BizTalk 2006
Windows SharePoint Services adapter
--------------------[vbcol=seagreen]
<MztnDzBkGHA.2260@TK2MSFTNGXA01.phx.gbl>[vbcol=seagreen]
with[vbcol=seagreen]
have[vbcol=seagreen]
(pool[vbcol=seagreen]
Should[vbcol=seagreen]
each[vbcol=seagreen]
with[vbcol=seagreen]
im[vbcol=seagreen]
to[vbcol=seagreen]
is[vbcol=seagreen]
maximum[vbcol=seagreen]
microsoft.public.biztalk.appintegration:8504[vbcol=seagreen]
daemon[vbcol=seagreen]
class.[vbcol=seagreen]
connections[vbcol=seagreen]
GNATS[vbcol=seagreen]
error:[vbcol=seagreen]
because[vbcol=seagreen]
|
|
|
|
|