Anyone having issue with email notification delay in ES4?

[lc_newbee]

After upgrade from ES2 to ES4, we're experiencing an email notification delay when a task is assigned to an individual or group queue. It's not consistent, but happen enough that we can some what replicate it. It's almost like an email notification from task assignment wouldn't send through until we kick off another process or claim another task. This happens with server default email notification as well as custom email notification. Please advise how I can go about trouble shooting this.

[wasil_z]

I'd suggest you to look for two things - In workspace preferences, user has choice to disable the notifications and delay might be caused by load on the server, there should be something like this on the server: http://blogs.adobe.com/livecycle/2010/07/work_policy_violations_in_live.html

-Wasil

[lc_newbee]

How do livecycle define once a task is completed? What I noticed is when a task is assigned to a user and even if the user already completed the task (task status shown as completed in admin ui) but the completed date value is still null. Because of this, LC process instance still think that this task is not truely completed yet, thus, it does not send the email notification. Until I start up a brand new process, the completed date is generated and email notification sent out.

[lc_newbee]

I don't know if this also help, but I'm getting this new error in the log:

XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@3a503a50#tid=2184317 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s

[wasil_z]

Ignore that . Attach the complete logs here.

[lc_newbee]

This is what in the log at the time I ran the test process & email notification delay occured. Again, the email notification delay wasn't the issue when we were in ES2, until we upgraded to ES4 recently. The delay happens spontaneously, no specific pattern. Sometimes it'll arrive instantly and sometimes it will delay. However, when the notification delay occur, if I kick off another new process, the notification will come through.

[1/21/15 10:27:47:442 CST] 00000031 ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [LiveCycleES4] [/adminui] [/secured/about.jsp]: Initialization successful.

[1/21/15 10:28:03:107 CST] 00000040 CSRFFilter    I   Fetched allowed referer list for servlet:/CoreSystemConfigComponent

[1/21/15 10:28:03:200 CST] 00000040 Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#bed5ed34fb984a88466db43f9ab1cef8"

[1/21/15 10:28:03:684 CST] 00000040 ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [LiveCycleES4] [/CoreSystemConfigComponent] [/secured/welcome.jsp]: Initialization successful.

[1/21/15 10:28:03:746 CST] 00000040 ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [LiveCycleES4] [/CoreSystemConfigComponent] [FilterProxyServlet]: Initialization successful.

[1/21/15 10:28:06:680 CST] 00000040 ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [LiveCycleES4] [/CoreSystemConfigComponent] [/secured/config.jsp]: Initialization successful.

[1/21/15 10:28:30:972 CST] 00000031 Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#a8bc74a810dee608d866cdf3d19861ab"

[1/21/15 10:28:30:988 CST] 00000031 Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#e83cca4f938a1d9f21e821a8c3663008"

[1/21/15 10:29:46:283 CST] 00000043 Authenticatio W   Authentication failed for user [abc] (Scheme - Username/Password) Reason: Username or password is incorrect . Refer to debug level logs for category com.adobe.idp.um.businesslogic.authentication for further details

[1/21/15 10:29:49:278 CST] 00000031 Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#f145055ebb4cb72241a696e2e37912b6"

[1/21/15 10:36:17:867 CST] 0000002d J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@3c103c10#tid=2172366 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:37:33:515 CST] 00000055 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@7c5a7c5a#tid=2172587 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:37:35:980 CST] 000000bf Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#b1ff24709e2764c4fdf7c8f5459a3f3c"

[1/21/15 10:37:38:570 CST] 000000c0 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@1fbd1fbd#tid=2173407 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:37:42:673 CST] 000000c0 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@3da43da4#tid=2174482 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:38:09:428 CST] 0000002d J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@26002600#tid=2176826 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:38:38:258 CST] 00000055 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@50165016#tid=2177247 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:39:09:272 CST] 00000054 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@26222622#tid=2179048 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:39:21:597 CST] 00000030 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@2b402b40#tid=2179505 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:40:07:291 CST] 00000055 Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#ea6a84b4552fffe36b7a86269d7b67d0"

[1/21/15 10:41:52:938 CST] 00000033 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@3a503a50#tid=2184317 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:42:21:160 CST] 0000002d J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@56fd56fd#tid=2184783 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:42:24:218 CST] 000000c3 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@276a276a#tid=2186778 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:42:28:071 CST] 000000c2 ProcessRecord W   deleting oldest recording(s) due to space limitation.

[1/21/15 10:42:29:943 CST] 000000c2 J2EEConnectio W   Service: XMLFormService resource: ProcessResource@5c105c1(name=XMLForm.exe,pid=5908) could not schedule an interrupt for transaction: com.ibm.ws.tx.jta.TransactionImpl@3c5e3c5e#tid=2188110 because excessive time was spent waiting in queue. Supplied timeout: 0s, Wait adjustment: 0s, Effective timeout: 0s.

[1/21/15 10:51:15:603 CST] 0000002f Reference     I org.apache.xml.security.signature.Reference verify Verification successful for URI "#c536f8c15947c0e0d16970ced8d90811"

[wasil_z]

Nothing relevant in the above logs. I'd suggest you to contact Adobe Enterprise Support and work with a support engineer to identify the issue.

-Wasil

[lsmurph]

Just for the record, I have experienced the same behavior that intermittently the email notification and subsequent task assignment does not go through until I kick off another process.  Any help from Adobe on this issue?

[SeanLapointe]

Has anyone ever gotten any information from Enterprise Support on this issue? We are experiencing this type of behaviour as well.

[kaloisio]

We are also experiencing the same issue in our ES4 environment. I noticed from the last comment that is still happening (in September 2016) as the original post in January 2015

Can anyone give us suggestions or tips to fix this?

[wasil_z]

In your application server, pass the JVM argument -Dmail.debug=true and check the application server logs for some additional information.

[SeanLapointe]

I ended up submitting a ticket to Enterprise support and they directed me to change my java options. They didn't give me this link, but the option I changed, a brief blurb on what it does, and how it can solve the issue can be found here:

https://helpx.adobe.com/aem-forms/kb/process-status-work-manager-admin-ui-not-updated.html

I've been running the solution for about two weeks now. It seems to have solved my problem.

[kaloisio]

Thanks for the solution Sean!

We applied it into production about 2 weeks ago and it appears to have solved our problems too.

Thanks again

Kris