PASOE 12.2 APSV Issues

Posted by Darren Parr on 14-Apr-2020 13:51

Hi

After upgrading, it seems I have a big issue getting this to work. Our system uses state-reset connections in classic appserver. This has always worked great with PASOE. We have code which bends the connection in the connect procedure and unbounds in the disconnect procedure as well as quits.

Since upgrading to 12.2 this application does not run. Moreover it crashes PASOE so no other connections are possible. As part of the login procedure, we use the connect procedure to return a list of resources as a custom error message which our client reads and utilises. This is how we implement our two stage login procedure. Unfortunately throwing an apperror is mostly lost to the client and the client throws an error of its own. 

This has worked in 12.0 and 12.1 but does not work in 12.2.

Any ideas? Otherwise its back to 12.1. This is not usable at the moment.

Regards

Darren

All Replies

Posted by Darren Parr on 14-Apr-2020 14:11

On further investigation, it raises the stop condition after a lengthy pause and then gives you an error on screen.

Error on connectRq() : com.progress.appserv.broker.exception.BrokerException$NoAvailableConnectionsException: Agent:No Available Connections[cannot start new agent]:Agent. (18298)

Posted by Darren Parr on 14-Apr-2020 15:57

OK. I can verify that I cannot return error from an appserver connect procedure under 12.2 PASOE. This leads to a long pause, the error I stated above and DISCONNECTION from the database by PASOE. Subsequent connection attempts just time out.

I'm going to assume this is a major bug and kills any kind of security via the connect procedure. I guess I can workaround it but it involves allowing anonymous connections to the appserver.

I'll log it.

Posted by Shelley Chase on 14-Apr-2020 16:02

Thank you. We will take a look once its logged with tech support.

-Shelley

Posted by Irfan on 14-Apr-2020 17:00

Darren,

When I return an error in connect procedure, I see that it is returned back to the client program. I am just doing a return error in my connect.p which is running a State-Reset mode. Once we get the example in the bug we might be able to find what is the exact use-case and how the errors are returned to the client. While you are doing that, please also add all the logs to the bug.

Thank you !

Posted by David Cleary on 14-Apr-2020 17:52

Missed that this was working in 12.1. Will investigate.

Posted by David Cleary on 14-Apr-2020 18:19

Can you provide us with your connect procedure? We confirmed our nightly tests that test this functionality is passing, so we need to see why it is failing for you.

Posted by Darren Parr on 15-Apr-2020 13:12

I've just reproduced this for TS. It's not complex but I think I know why its occurring.

Essentially I created a connect.p and disconnect.p and put them in the openedge folder. The connect.p sets server-connection-bound-request to true and does a return error "test message". The disconnect.p unsets the server-connection-bound-request and does a QUIT. Just do a connect to an appserver handle with the correct parameters (session-managed of course) and it'll fall over.

Note that the reason this is falling over is more to do with the fact that I'm using a development (1 agent, 5 concurrent) PASOE instance. I believe the agent gets trashed as a result of the return error and you get a massive timeout message on the client as a result. It pauses for 5 or so seconds. With a production instance the situation is perhaps different due to the fact that other agents are available... I'm guessing  here...

HTH

Darren

Posted by Irfan on 15-Apr-2020 13:18

Thank you Darren. I am kind of using same use-case here, but I tried in a Production environment. I will try to get the repro from TS and see how it is behaving in development and production. Thank you for the details again.

Posted by Darren Parr on 16-Apr-2020 17:13

This has now been confirmed and reported as a defect. From the comments here I think it relates to how PASOE handles that error and I believe a development single agent instance is perhaps not able to cope.

Assuming I am correct then I guess all OEDK basic users can't run a system that does this.

Regards

Darren

This thread is closed