Package Build Error

I recently installed a new Win2000 apps server and I am attempting to build a full package. When building BSFN - I get the following error over and over in the jde.log on the apps server and no DLLs build. Has anyone ever seen this error?

10054-send returned 10054 (WSAECONNRESET): Connection was reset by peer

Thanks!
Melissa

How is the server configured? What are the specs for your installation? Have you installed C++? etc...

WSAECONNRESET Error on Win2000 apps server

I am getting the following error over and over again in my jde.log on my 2 win2000 apps servers:

10054-send returned 10054 (WSAECONNRESET): Connection was reset by peer

It is causing huge perfomance issues towards the end of the day to where I have to reboot the apps servers nightly. I have seen previous posts on here with the same problem on a citrix server and the suggestion was to set NetTrace=1 in the ini. NetTrace is already set to 1 in my Apps Server ini. Does anyone else have any other suggestions?

I am ERP 8 SP21 Oracle on SUN. I have 2 Win2000 Apps servers (one acting as Security Server).

Thanks!

Re: WSAECONNRESET Error on Win2000 apps server

Check and see if you are having network issues. Example: frame errors, bad packets, auto-negotiation problems, etc... you should see these either by using a sniffer or by looking at your switches and routers.

Re: WSAECONNRESET Error on Win2000 apps server

Thank you for the suggestion but we have already tested that. JDE sent me the below document but I am not really sure what the fix is.

Thanks!
Melissa

SAR # 3343287 describes this.

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.