Knowledge Partner
Knowledge Partner

Re: eDir driver connections getting stuck in CLOSE_WAIT state

matt wrote:

> Support suggested writing a script to change an object on each side
> every few minutes to keep the connection alive, which we've done. It
> works, but I find this solution somewhat unacceptable.


Why don't run a simple trigger job on both drivers? I think triggers are send
over the wire, ad if not, just convert them to a status in OT. Same effect,
more acceptable and without external components... or are you still on some 3.x
version?
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir driver connections getting stuck in CLOSE_WAIT state


RESOLVED:

I ran into this same issue this week. Our eDir to eDir drivers would
loose connection after only 2 minutes of no activity. They are connected
through a firewall.

We were going to go the trigger job on both sides, but ended up not
needing it.

We added this config on the Driver in the Subscriber and the Publisher
options on both drivers, and it solved the problem (See below).

- <definition display-name="Receive timeout in
minutes" name="keep-alive-interval" range-lo ="1" type="integer">
<description>
In order to detect a
lost TCP/IP connection the eDirectory to eDirectory driver periodically
sends
small packets. This
value determines how long since entering a receive-wait condition the
publisher(subscriber)
channel will wait until sending a "keep-alive" packet to determine if
the TCP/IP
connection has been
lost. Generally this value should not be changed except under
instruction
from Novell. The default
value for the publisher channel is ten minutes. The default value for
the subscriber channel is 1 minute.
</description>
<value>1</ value>
</definition>

-


--
ckynaston
------------------------------------------------------------------------
ckynaston's Profile: https://forums.netiq.com/member.php?userid=7175
View this thread: https://forums.netiq.com/showthread.php?t=49883

0 Likes
Knowledge Partner
Knowledge Partner

Re: eDir driver connections getting stuck in CLOSE_WAIT state

ckynaston wrote:

> We added this config on the Driver in the Subscriber and the Publisher
> options on both drivers, and it solved the problem (See below).
>
> - <definition display-name="Receive timeout in
> minutes" name="keep-alive-interval" range-lo ="1" type="integer">
> <description>


Cool! I did not know this driver parameter even exists...
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir driver connections getting stuck in CLOSE_WAIT state


ckynaston;243030 Wrote:
> RESOLVED:
>
> I ran into this same issue this week. Our eDir to eDir drivers would
> loose connection after only 2 minutes of no activity. They are connected
> through a firewall.
>
> We were going to go the trigger job on both sides, but ended up not
> needing it.
>
> We added this config on the Driver in the Subscriber and the Publisher
> options on both drivers, and it solved the problem (See below).
>
> - <definition display-name="Receive timeout in
> minutes" name="keep-alive-interval" range-lo ="1" type="integer">
> <description>
> In order to detect a
> lost TCP/IP connection the eDirectory to eDirectory driver periodically
> sends
> small packets. This
> value determines how long since entering a receive-wait condition the
> publisher(subscriber)
> channel will wait until sending a "keep-alive" packet to determine if
> the TCP/IP
> connection has been
> lost. Generally this value should not be changed except under
> instruction
> from Novell. The default
> value for the publisher channel is ten minutes. The default value for
> the subscriber channel is 1 minute.
> </description>
> <value>1</ value>
> </definition>
>
> -



We tried that but that did not work for this customer. It still stopped
and would not re-open. We had to go with the trigger job.

Matt


--
matt
------------------------------------------------------------------------
matt's Profile: https://forums.netiq.com/member.php?userid=183
View this thread: https://forums.netiq.com/showthread.php?t=49883

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.