Affects Version/s: 6.1.20 EE GA2
Environment:Local and production environments. We previously were at fixpack core 3. We did not install fixpack core 4.
Linux variants. Tomcat app server - 7.0.27.
We have recently incorporated the inbound message board functionality into our product feature set. Prior to installing the Fixpack Core 5 - this was working correctly (with some minor patches - refer to
However, after installing the Core5 patch, we noticed that this functionality ceased to work.
The easiest way to replicate the issue is by initially having an environment that does NOT contain Core 5:
- enable support for inbound messages via POP3 in portlet-ext.properties - and have it poll for messages every minute
- restart the server
- in the control panel under -> Server -> Server Admin -> Mail - add credentials to a test pop3 account but make sure that either username or password is incorrect
At this point you should note that every minute there are ERROR messages within the Console/Logs that are from the POPNotificationsMessageListener saying that it authentication failed.
Now go ahead and install the Fixpack Core 5:
- Stop server
- move fixpack to /patching-tool/patches directory
- run ./patching-tool.sh install
- Restart the server
What you should now witness is that these messages no longer appear in the logs. And this is where I am now stuck and seem to get no closer to an answer despite having tried the following:
- thread dump for both scenarios above -> saw no relevant differences between the threads
- running the server in debug mode in both scenarios. If I put breakpoints in the POPNotificationsMessageListener class for example - I'm only getting a hit when the Core5 fixpack is uninstalled.
- upping the logging verbosity across a number of different packages (i've attached a copy of my portal-log4j-ext.xml file that I've been using
- removing what appear to be relevant .class files from the Core 5 fixpack codebase in an attempt to see if any of these are responsible:
- com.liferay.portal.kernel.messaging.BaseAsyncDestination/ParallelDestination & SerialDestination
For now our option is to either fake this out by monitoring our inbound queue and manually recreating these messages in the relevant messageboard – or rolling out the Core 5 fix pack.
I would really like to get confirmation that someone else is seeing this and hopefully a suggestion or solution.
If I can provide any more information in getting this resolved - please let me know what you need.