Hello,
my jtapi app is working fine, after some days, it's unable to connect to AES and we're getting this error: error 1005 < DRIVER_RESOURCE_LIMITATION >

Did someone experienced similair problem, how to fix it. Here's the relevant part of the jtapi log, the whole log is available and could be uploaded if necessary.

2019-10-29 13:54:40 DEBUG TsapiSession:657 - ACSOpenStream ::=

2019-10-29 13:54:40 DEBUG TsapiSession:657 - {

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   streamType 1 < ST_CSTA >

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   serverID "AVAYA#ACMFES#CSTA#AES-FES1"

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   loginID "cticad"

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   cryptPass ce c8 49 42 9c d5 df cc fe 32 1 44 d4 e0 57 b8 d8 47 1c d3 d4 e0 57 b8 d8 47 1c d3 d4 e0 57 b8 d8 47 1c d3 d4 e0 57 b8 

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   applicationName "Jtapi Client"

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   level 1 < ACS_LEVEL1 >

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   apiVer "TS1:2"

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   libVer "AES8.1.0.0.0.9"

2019-10-29 13:54:40 DEBUG TsapiSession:657 -   tsrvVer ""

2019-10-29 13:54:40 DEBUG TsapiSession:657 - }

2019-10-29 13:54:40 DEBUG TsapiSession:671 - TsapiPrivate ::=

2019-10-29 13:54:40 DEBUG TsapiSession:671 - {

2019-10-29 13:54:40 DEBUG TsapiSession:671 -   vendor "VERSION"

2019-10-29 13:54:40 DEBUG TsapiSession:671 -   data 0 45 43 53 23 34 2d 31 35 23 41 54 26 54 20 44 65 66 69 6e 69 74 79 20 47 33 23 34 2d 31 35 0 

2019-10-29 13:54:40 DEBUG TsapiSession:671 -   tsType 0

2019-10-29 13:54:40 DEBUG TsapiSession:671 - }

2019-10-29 13:54:44 INFO  TsapiSession:751 - Received invokeID 2 for TSProvider[#949]@a1efabc

2019-10-29 13:54:44 DEBUG TsapiSession:759 - ACSUniversalFailureConfEvent ::=

2019-10-29 13:54:44 DEBUG TsapiSession:759 - {

2019-10-29 13:54:44 DEBUG TsapiSession:759 -   error 1005 < DRIVER_RESOURCE_LIMITATION >

2019-10-29 13:54:44 DEBUG TsapiSession:759 - }

2019-10-29 13:54:44 INFO  TSInvokeID:51 - Handling INVOKE ID 2 for TSProvider[#949]@a1efabc

2019-10-29 13:54:44 INFO  TSInvokeID:55 - DONE handling INVOKE ID 2 for TSProvider[#949]@a1efabc

2019-10-29 13:54:44 DEBUG TsapiSession:759 - ACSUniversalFailureEvent ::=

2019-10-29 13:54:44 ERROR TsapiSession:381 - Tsapi<init>: com.avaya.jtapi.tsapi.TsapiPlatformException: ACS Error: 1005

2019-10-29 13:54:44 ERROR Tsapi:226 - Tsapi<init>: com.avaya.jtapi.tsapi.TsapiPlatformException: ACS Error: 1005

2019-10-29 13:54:44 INFO  TsapiSession:652 - Sent InvokeID 3 for TSProvider[#949]@a1efabc

2019-10-29 13:54:44 DEBUG TsapiSession:657 - ACSAbortStream ::=

2019-10-29 13:54:44 DEBUG TsapiSession:657 - {

2019-10-29 13:54:44 DEBUG TsapiSession:657 -   NULL

2019-10-29 13:54:44 DEBUG TsapiSession:657 - }

2019-10-29 13:54:44 DEBUG TsapiSession:759 - {

2019-10-29 13:54:44 DEBUG TsapiSession:759 -   error 66 < TSERVER_NO_ACS_STREAM >

2019-10-29 13:54:44 DEBUG TsapiSession:759 - }

2019-10-29 13:54:44 INFO  TsapiEventQueue:176 - Putting event CSTAEvent[ACSUniversalFailureEvent]@40052e69. EVENT Q SIZE = 1 MAX Q SIZE = 1 for TSProvider[#949]@a1efabc

2019-10-29 13:54:44 ERROR AvayaConnectionRetry:46 - FAILED IN CONNECTING TO AVAYA..Skipping JTAPI monitoring

com.avaya.jtapi.tsapi.TsapiPlatformException: ACS Error: 1005

	at com.avaya.jtapi.tsapi.tsapiInterface.TSErrorMap.throwACSException(TSErrorMap.java:56)

	at com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession.send(TsapiSession.java:582)

	at com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession.send(TsapiSession.java:465)

	at com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession.startSession(TsapiSession.java:359)

	at com.avaya.jtapi.tsapi.tsapiInterface.Tsapi.init(Tsapi.java:222)

	at com.avaya.jtapi.tsapi.tsapiInterface.TsapiFactory.getTsapi(TsapiFactory.java:42)

	at com.avaya.jtapi.tsapi.impl.core.TSProviderImpl.<init>(TSProviderImpl.java:389)

	at com.avaya.jtapi.tsapi.impl.TsapiProvider.<init>(TsapiProvider.java:83)

	at com.avaya.jtapi.tsapi.impl.TsapiPeerImpl.getProvider(TsapiPeerImpl.java:34)

	at com.avaya.jtapi.tsapi.TsapiPeer.getProvider(TsapiPeer.java:58)

	at com.avaya.jtapi.core.JTAPIInitializer.connect(JTAPIInitializer.java:73)

	at com.avaya.jtapi.core.AvayaCallMonitor.initialize(AvayaCallMonitor.java:59)

	at com.avaya.jtapi.core.AvayaCallMonitor$$FastClassBySpringCGLIB$$5b861412.invoke(<generated>)

	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)

	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:684)

	at com.avaya.jtapi.core.AvayaCallMonitor$$EnhancerBySpringCGLIB$$25e0d27.initialize(<generated>)

	at com.avaya.jtapi.core.AvayaConnectionRetry$1.run(AvayaConnectionRetry.java:43)

	at java.lang.Thread.run(Thread.java:748)

2019-10-29 13:54:44 INFO  AvayaConnectionRetry:41 - TRYING CONECTING TO AVAYA

2019-10-29 13:54:44 INFO  JTAPIInitializer:69 - *** AVAYA Connect called

2019-10-29 13:54:44 INFO  TSProviderImpl:337 - TSProvider: version '8.1.0.0.0.9 [production build]', for TSProvider[#950]@6b1af093

2019-10-29 13:54:44 INFO  TSProviderImpl:385 - TSProvider: calling acsOpenStream serverID=AVAYA#ACMFES#CSTA#AES-FES1 loginID=cticad passwd=******* for TSProvider[#950]@6b1af093

Thank you,

DRIVER_RESOURCE_LIMITATION = The driver did not have adequate resources (that is memory, etc.) to complete the requested operation. This is an internal error and should be reported

Have you tried rebooting your AE Services?

Martin

Thank you for your reply,
It's a production server and I haven't tried to reboot it.
I've two virtual servers, running on two physical servers, one running AES, the other is running the JTAPI client.
Do you mean that the reason is AES server running out of resources?
I've access to the jtapi server, and I'm the author of the jtapi app, I've even rebooted it, but the problem persisted.

I don't have access to AES server, but I need to write down a report to the customer. Could I say, jtapi server has nothing to do with the problem, and resources on AES server should be checked?
Thank you again

Another question please, could a network problem be the cause? TBH both servers are on the same LAN and pings never fail between the two servers, I'm just wondering.

1) Once the problem is seen, can you connect to the AES using an alternative tool like the JTAPI Exerciser using the same credentials from the same application server?
2) I read the description of the 1005 error to indite the driver in the AES server, but a packet trace or log files from AES would be helpful to make that clear.
3) I read your message to imply that the connection works for some number of days and then fails, and cannot be recovered... even after rebooting the application server. If that is the case, that is odd, but also points to the AES server being the problem. Is the server under maintenance? Can you open an Avaya support request against the server? Is the server resourced properly? Is the underlying hardware sufficient to host the VMs running on it? Are there other applications successfully using the AES in the interval that your application has connection issues?

JohnBiggs wrote:1) Once the problem is seen, can you connect to the AES using an alternative tool like the JTAPI Exerciser using the same credentials from the same application server?

> haven't made such test, but will do.

2) I read the description of the 1005 error to indite the driver in the AES server, but a packet trace or log files from AES would be helpful to make that clear.

>I've transferred this request to the person in charge (Avaya certified technicien) on customer site to retrieve such logs.

3) I read your message to imply that the connection works for some number of days and then fails, and cannot be recovered... even after rebooting the application server. If that is the case, that is odd, but also points to the AES server being the problem. Is the server under maintenance? Can you open an Avaya support request against the server? Is the server resourced properly? Is the underlying hardware sufficient to host the VMs running on it? Are there other applications successfully using the AES in the interval that your application has connection issues?

>The server is in production, TBH, there's many servers but the problem seems to appear on sites with heavy load, the customer is going to open an Avaya ticket against one of them. As for resources, I did a request to get allocated RAM, CPU, Disk to Avaya VMs.
The only things that works now, is operators being able to login and receive calls.

I'll come back with more details once I get some feedback from customer.

Hello,
when the problem appears here's the output of the top command https://www.unidev.com.tn/top_irp.png . The tsrv process is taking all CPU.
RAM allocated to AES OVA is 4GB, number of agents supervised by jtapi app: 24. Do you think I need to increase allocated RAM?

We can't advise you on configuration of a production system. However, 4GB does seem to be consistent with the recommendations in "Deploying Avaya Aura Application Enablement Services in Virtualized Environment".

As the TSAPI service is running hot, I suspect that some application is bombarding it with requests. If your customer opens a service request, Avaya Services should be able to investigate this.

Martin

Thank you Martin