Symptoms

A subscription cannot be destroyed.

Cancellation order fails with the output:

Removal of Service of Subscription #1000576 is failed. Parallels Operations Automation error #error_code #1, extype_id #1, module_id #Subscriptions, javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.GenericJDBCException: could not prepare statement.

"Destroy" button click results in apache Error 503. In /var/log/pa/core.log exception can be seen, which occurs in 5 minutes from method start:

Sep 25 09:17:23.143 : DBG [openapi:768089 openapi-task-106:674 pau]: c.p.p.s.x.c.CorbaMethodInvokerImpl calling CORBA operation: removeSubscription({subscription_id=1000001})
Sep 25 09:17:23.144 : DBG [openapi:768089 1:14080:7fe2537f7700 AutoProvisioningManager ]: [ OpenAPI::ProvisioningOpenAPI_impl::removeSubscription] ===> ENTRY
...
Sep 25 09:22:23.228 : ERR [openapi:768089 1:14873:7f3eb18d8700 SAAS 1587569472]: [ SaaS::deletePOAResource] APS resource for /aps/2/application/websites/a0d1540d-8b79-4a59-a691-cb8abb1111f1 1234 was NOT deleted. Response code: 500
Sep 25 09:22:23.229 : DBG [openapi:768089 1:14873:7f3eb18d8700 lib 1587569472]: [ SaaS::deletePOAResource] {module_id="SaaS"; code="37"} APS resource for '/aps/2/application/websites/a0d1540d-8b79-4a59-a691-cb8abb1111f1' with id '1234' was NOT deleted. Error code: 500.
Sep 25 09:22:23.229 : DBG [openapi:768089 1:14873:7f3eb18d8700 SAAS 1587569472]: [ APS::APSManager_impl::onRemoveWebsite] <=== EXIT (by exception) [0.430710]
Sep 25 09:22:23.235 : DBG [openapi:768089 p:-default-threadpool;-w:-Idle:3484 pau]: c.p.p.s.o.e.ObserverManagerBean Corba exception on observer invocation, observerClass: RemoveWebsiteObserver, scId: 50org.omg.CORBA.OBJECT_NOT_EXIST:
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

Another error example for an Office 365 subscription:

Jan  4 00:08:03.683 : DBG [openapi:29 RequestProcessor-25 pau 1182906672]: c.p.p.tracer exit by exception: com.parallels.pa.service.subscriptions.ejb.SubscriptionsBean.deleteSubscriptionjavax.ejb.EJBTransactionRolledbackException: Server-side Exception: null
Jan  4 00:08:03.684 : DBG [openapi:29 RequestProcessor-25 pau 1182906672]: c.p.p.tracer exit by exception: com.parallels.pa.service.subscriptions.ejb.SubscriptionsBean.unsubscribejavax.ejb.EJBException: javax.ejb.EJBTransactionRolledbackException: Server-side Exception: null
Jan  4 00:08:03.685 : DBG [openapi:29 RequestProcessor-25 pau 1182906672]: c.p.p.c.ServiceInvoker CORBA SystemException which caused EJB exception found: org.omg.CORBA.OBJECT_NOT_EXIST: Server-side Exception: null

Another example of log messages:

Oct  4 17:29:35.340 : DBG [openapi:2254 p:-default-threadpool;-w:-Idle:1202 pau]: c.p.p.tracer exit by exception: com.parallels.pa.service.resources.ejb.ResourceManagementBean.getResourceActivationParametersMap correlationId openapi:2254javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not prepare statement
...
Caused by: java.sql.SQLException: IJ031070: Transaction cannot proceed: STATUS_ROLLEDBACK
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.checkTransactionActive(WrapperDataSource.java:245)
        at org.jboss.jca.adapters.jdbc.WrappedConnection.checkTransactionActive(WrappedConnection.java:1928)
        at org.jboss.jca.adapters.jdbc.WrappedConnection.checkStatus(WrappedConnection.java:1943)
        at org.jboss.jca.adapters.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:1917)
        at org.jboss.jca.adapters.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:447)

Cause

The subscription has many objects that needs to destroyed (e.g. >500 Apache websites or >2000 Office 365 users), the current PAU timeout is too low for this operation to be completed.

The time required to complete subscription removal is also affected by the total amount of subscriptions under the account.

The behavior is acknowledged as POA-116997.

Resolution

Increase PAU timeout as described in the article 130501. Study the log files to see how many objects managed to be processed within 5 minutes to estimate the target timeout.

Internal content