No MBMessage exists with the primary key XXX

[Jan Tošovský, modificado hace 8 años.]

Dear All,

whereas many times replying to messages is Ok, from time to time I am getting this exception. It got worse recently. I have proof that message is already stored in database, but when trying to edit this recent reply, nothing is found. And similarly, when trying to reply to this recent post, a new thread is to be created instead.

In the stacktrace I don't see any suspicious handling, just standard calls. LR 6.2.2 + postgreSQL.

16:44:21,161 ERROR [ajp-nio-8009-exec-101][render_portlet_jsp:132] null
com.liferay.portlet.messageboards.NoSuchMessageException: No MBMessage exists with the primary key 4524068
	at com.liferay.portlet.messageboards.service.persistence.MBMessagePersistenceImpl.findByPrimaryKey(MBMessagePersistenceImpl.java:19490)
	at com.liferay.portlet.messageboards.service.persistence.MBMessagePersistenceImpl.findByPrimaryKey(MBMessagePersistenceImpl.java:19508)
	at com.liferay.portlet.messageboards.service.impl.MBMessageLocalServiceImpl.getMessage(MBMessageLocalServiceImpl.java:1072)
	at com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:67)
	at com.liferay.portlet.messageboards.service.MBMessageLocalServiceWrapper.getMessage(MBMessageLocalServiceWrapper.java:641)
	at com.liferay.portlet.messageboards.service.MBMessageLocalServiceWrapper.getMessage(MBMessageLocalServiceWrapper.java:641)
	at com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:67)
	at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:115)
	at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.execute(DefaultTransactionExecutor.java:62)
	at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:51)
	at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:111)
	at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:175)
	at com.liferay.portlet.messageboards.service.MBMessageLocalServiceUtil.getMessage(MBMessageLocalServiceUtil.java:595)
	at com.liferay.portlet.messageboards.service.permission.MBMessagePermission.contains(MBMessagePermission.java:64)
	at com.liferay.portlet.messageboards.service.permission.MBMessagePermission.check(MBMessagePermission.java:44)
	at com.liferay.portlet.messageboards.service.impl.MBMessageServiceImpl.getMessage(MBMessageServiceImpl.java:512)
	at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:115)
	at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.execute(DefaultTransactionExecutor.java:62)
	at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:51)
	at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:111)

It is failing in the customized EditMessageAction, actually in render method:

    @Override
    public String render(StrutsPortletAction originalStrutsPortletAction, PortletConfig portletConfig, RenderRequest renderRequest, RenderResponse renderResponse) throws Exception {
        return originalStrutsPortletAction.render(null, portletConfig, renderRequest, renderResponse);
    }

Here I just pass params to the default render method.

Any idea?

Thanks, Jan

[Olaf Kock, modificado hace 8 años.]

Any chance that anyone modified the database manually? It might be that the MBMessage entry is there, but none of the required foreign key relationships (or at least a critical one missing). Unexplainable behaviour like this often is traced back to manually writing to the database. Note: This might have happened looooooooooong time ago

[Jan Tošovský, modificado hace 8 años.]

Thanks, but in this case I believe the cause is different.

I suspect some caching issue (or unfinished service call). When a new reply is created, it is displayed at the end of thread (flat) view correctly, but any subsequent message retrieval via LocalServiceUtil.getMessage(messageId) throws an error (No Such Message). When I log myself out and log in again, that message is retrieved without problems.

Now I am trying to find why displaying the message within the thread works immediately.

[Jan Tošovský, modificado hace 8 años.]

Further investigation revealed:
MBMessagePersistence.findByThreadId(threadId) returns collection inclusive newly created reply (with PK=XXX)
MBMessagePersistence.findByPrimaryKey(XXX) returns No MBMessage exists with the primary key XXX

This explain why that message is displayed within its thread correctly, but it cannot be found when it is requested directly.

Has anybody any idea why such a difference?

[Jan Tošovský, modificado hace 8 años.]

My current solution is to hook two action helpers (adding MBMessageUtil.clearCache() to various places):
ViewMessageAction.java

    @Override
    public String render(StrutsPortletAction originalStrutsPortletAction, PortletConfig portletConfig, RenderRequest renderRequest, RenderResponse renderResponse) throws Exception {

        // when reply is rendered, it must be ready
        MBMessageUtil.clearCache();

        return originalStrutsPortletAction.render(null, portletConfig, renderRequest, renderResponse);          
    } 

EditMessageAction.java

    @Override
    public String render(StrutsPortletAction originalStrutsPortletAction, PortletConfig portletConfig, RenderRequest renderRequest, RenderResponse renderResponse) throws Exception {

        // when replying on newly created reply the latter must be ready
        // when editing newly created reply it must be ready
        MBMessageUtil.clearCache();

        return originalStrutsPortletAction.render(null, portletConfig, renderRequest, renderResponse);
    }
    // customized method for specific needs
    protected MBMessage updateMessage(
            ActionRequest actionRequest, ActionResponse actionResponse)
            throws Exception {
            ...
            // test for subscribe requires the current message to be present
            MBMessageUtil.clearCache();

            if (!preview && subscribe
                    && permissionChecker.hasPermission(message.getGroupId(), MBMessage.class.getName(),
                            message.getMessageId(), ActionKeys.SUBSCRIBE)) {

                MBMessageServiceUtil.subscribeMessage(message.getMessageId());
            }
            ...
    }

Now all errors seem to be eliminated, but will monitor if this change is sufficient.

[Olaf Kock, modificado hace 8 años.]

Good catch. Could you check if this still exists on 6.2 GA5? If it does, please file an issue on https://issues.liferay.com (if it isn't already there). Your description is quite good and should help find the root cause, if it hasn't long been found&fixed (thus the question for GA5 reproducability).