Hi, 

My customer has the same error in App9.  

Did you find a solution for this by increasing a parameter value somewhere?

The reason is  a huge size of GL transactions in multi-company environment, I think.  Customer is asked to start archive old GL transactions by the standard functionality.  If there is a solution with more optimal  parameter setup, it would be good to take into use.

I am dealing with the same issue. I have not came across a valid solution yet. the stack trace is as follows:
 

Ifs.Fnd.FndSystemException: Server Error ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)

   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

   --- End of inner exception stack trace ---

   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

   at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)

   at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)

   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)

   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)

   --- End of inner exception stack trace ---

Server stack trace:

   at Ifs.Fnd.AccessProvider.FndConnection.CallGetResponse(String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Byte[] requestHeaderBytes, Byte[] requestBodyBytes, FndApfAsyncInvoke asyncInvokeHandle, Boolean integrationGateway)

   at Ifs.Fnd.AccessProvider.FndConnection.AsyncGetResponse(String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Byte[] requestHeaderBytes, Byte[] requestBodyBytes, FndApfAsyncInvoke asyncInvokeHandle, Boolean integrationGateway)

   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)

   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:

   at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)

   at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)

   at Ifs.Fnd.AccessProvider.FndConnection.GetResponseDelegate.EndInvoke(IAsyncResult result)

   at Ifs.Fnd.AccessProvider.FndConnection.InvokeGetResponse(String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Byte[] requestHeaderBytes, Byte[] requestBodyBytes, Boolean& abandoned, Boolean forcedSync, Boolean integrationGateway)

   at Ifs.Fnd.AccessProvider.FndConnection.InvokeInternal(Object requestBody, Object responseBody, String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Boolean forcedSync, Boolean integrationGateway)

   --- End of inner exception stack trace ---

   at Ifs.Fnd.AccessProvider.FndConnection.InvokeInternal(Object requestBody, Object responseBody, String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Boolean forcedSync, Boolean integrationGateway)

   at Ifs.Fnd.AccessProvider.FndConnection.InvokeInternal(String intface, String operation, Object requestBody, Object responseBody, FndRequestContext requestContext, Boolean forcedSync, Boolean integrationGateway)

   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLCommandCollection.Invoke()

   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLCommand.ExecuteNonQuery()

   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLSelectCommandReader.Read(Boolean prepare)

   at Ifs.Fnd.Data.ADONetProvider.FndAPCommand.ExecuteDbDataReader(CommandBehavior behavior)

This is still unclear case. But I have got some hints it could be related with Load balancer , and it’s parameters.

Hi all, Was any fix found for this? We are also facing the same issue on APP 9.

Hi,

Customer’s production environment has Load balancer.

TCP Idle Timeout value in load balancer was increased  (from the original 300 s = 5min to 1800 s = 30 min)

Originally there was 10 min active communication time + 5 min idle time. Now it is 10+30 min, Which is long enough for generating heavy PDF reports.

Hi ​@PetriLahtinen, is it for IFS APP 9? And was the customer using an Azure Load Balancer?

Hi, bensubendran,

It is IFS APP9. Don’t know about the load balancer. To be honest, I am not a tech specialist.