Maestro19
Member
This issue is one that has continued to rear it testy little head everywhere I go. The problem of connectivity through Citrix Users has become extremely common at various client sites. The following message seems to be the point of error in the server log
original log attached )
"10054-Error from Host=0xc0a80f53 in recv returned 10054 (WSAECONNRESET): Connection was reset by peer." This problem is caused by jdenet failing to notify the kernel to release the user environment on the NT server when the client side of a socket connection is down.
Accordingly on the KG, it is explained this way:
"A ORIGINAL REQUEST
JDENet is not freeing user environments on the server when the OneWorld client abends. Apparently, NT tcp/ip sends a different event than Unix & 400. JDENet handles this problem fine on Unix & 400.
B FINAL DISPOSITION
The problem is caused by jdenet failing to notify the kernel to release the user environment on the NT server when the client side of a socket connection is down. Unix & AS/400 servers do not have this problem. An environment test is
added in processSocketEvent() to determine if it is a Windows environment during a FD_CLOSE event. If it is, readMsg() is called so that the kernel will be notified in the event of client abort.
Additional comments:
The user environment consumes resource on a OW server. This resource will be wasted if not freed after the OW client user aborts the network connection. Because the total allocatable server resource is limited, this problem can cause
serious deterioration of the server performance, especially on a busy server such as a web server. When a socket on NT server is set to "keep alive", it will flag different errors depending on the nature of the client shutdown. If the
client initiated a graceful shutdown, a FD_CLOSE event will be raised on NT server with a WSAENOTCONN error on the server socket doing a recv() or send(). If the client aborts, the server socket will issue a WSAECONNRESET error while
the same FD_CLOSE event is raised. The event processing logic, however, only tests these two different flags in readMsg() when a FD_READ event is raised, then notifies the kernel to release the user environment. During a normal client
shutdown, all queued packets will be read by the server before the server receives the FD_CLOSE. But if the client aborts, FD_CLOSE will be the only event the server receives. Therefore, the kernel notification logic will not be called in this
case. There is not a Windows-equivalent "event" concept in Unix. Jdenet "fakes" the event such as FD_READ and FD_CLOSE by checking the socket status returned by select(). This call sets the bit on the reading server socket when
the client aborts. Thus a FD_READ is issued by jdenet. The socket error checking logic in jdenet will detect the error and notify the kernel to free the user environment.
Does anyone else on the list have applicable suggestions or comments pertaining to this issue??? Thanks in advance for your assistance. This is definitely one for the archives!
original log attached )"10054-Error from Host=0xc0a80f53 in recv returned 10054 (WSAECONNRESET): Connection was reset by peer." This problem is caused by jdenet failing to notify the kernel to release the user environment on the NT server when the client side of a socket connection is down.
Accordingly on the KG, it is explained this way:
"A ORIGINAL REQUEST
JDENet is not freeing user environments on the server when the OneWorld client abends. Apparently, NT tcp/ip sends a different event than Unix & 400. JDENet handles this problem fine on Unix & 400.
B FINAL DISPOSITION
The problem is caused by jdenet failing to notify the kernel to release the user environment on the NT server when the client side of a socket connection is down. Unix & AS/400 servers do not have this problem. An environment test is
added in processSocketEvent() to determine if it is a Windows environment during a FD_CLOSE event. If it is, readMsg() is called so that the kernel will be notified in the event of client abort.
Additional comments:
The user environment consumes resource on a OW server. This resource will be wasted if not freed after the OW client user aborts the network connection. Because the total allocatable server resource is limited, this problem can cause
serious deterioration of the server performance, especially on a busy server such as a web server. When a socket on NT server is set to "keep alive", it will flag different errors depending on the nature of the client shutdown. If the
client initiated a graceful shutdown, a FD_CLOSE event will be raised on NT server with a WSAENOTCONN error on the server socket doing a recv() or send(). If the client aborts, the server socket will issue a WSAECONNRESET error while
the same FD_CLOSE event is raised. The event processing logic, however, only tests these two different flags in readMsg() when a FD_READ event is raised, then notifies the kernel to release the user environment. During a normal client
shutdown, all queued packets will be read by the server before the server receives the FD_CLOSE. But if the client aborts, FD_CLOSE will be the only event the server receives. Therefore, the kernel notification logic will not be called in this
case. There is not a Windows-equivalent "event" concept in Unix. Jdenet "fakes" the event such as FD_READ and FD_CLOSE by checking the socket status returned by select(). This call sets the bit on the reading server socket when
the client aborts. Thus a FD_READ is issued by jdenet. The socket error checking logic in jdenet will detect the error and notify the kernel to free the user environment.
Does anyone else on the list have applicable suggestions or comments pertaining to this issue??? Thanks in advance for your assistance. This is definitely one for the archives!
