[jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1626) FIrst access to a CMS HTML file through /content/ results in a NPE

[Sohil Shah (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1626?page=comments#action_12374858 ] 
            
Sohil Shah commented on JBPORTAL-1626:
--------------------------------------

This problem is becuase of weird locking issue that crops up with usage of jboss-cache-1.4.1. 

Thats the version packaged with 4.2.1.GA and the way to fix this is to remove the following jar file:

/server-config/lib/jboss-cache-jdk50.jar.

Compatibility with jboss-cache-1.4.1 will have to be looked into further, maybe even probably with some help from JBoss Cache team.

Digging deeper into the issue, in 1.4.1 jboss cache system seems to be timing out trying to grab a read lock on a cache node due to the presence of a write lock on that node.

However, in this usecase, there is clearly no write access being made to the jboss cache node (programmatically), so I am puzzled as to where the write lock on the node is coming from.

Everything works fine when the NodeLockingScheme is set to OPTMISTIC instead of PESSIMISTIC. But, this is not a solution.

For now, in JBoss-4.2.1, the /server-config/lib/jboss-cache-jdk50.jar needs to be deleted, so that the jboss-cache-1.4.0 packaged with the portal release will be used

> FIrst access to a CMS HTML file through /content/ results in a NPE
> ------------------------------------------------------------------
>
>                 Key: JBPORTAL-1626
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1626
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6.1 Final
>            Reporter: Thomas Heute
>         Assigned To: Sohil Shah
>            Priority: Critical
>             Fix For: 2.6.2 Final
>
>
> To reproduce, after startup go to:
> http://localhost:8080/portal/content/default/project.html
> It will fails to acquire a read lock resulting in a null content.
> It fails when trying to do:
>              VersionHistory vh = contentNode.getVersionHistory();
> in ContentGetCommand
> On the second rendering it will succeed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira