Bug 745923 (EDG-6) - NPE in CacheLoaderInterceptor
Summary: NPE in CacheLoaderInterceptor
Keywords:
Status: VERIFIED
Alias: EDG-6
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 6.0.0
Assignee: Tristan Tarrant
QA Contact: Nobody
URL: http://jira.jboss.org/jira/browse/EDG-6
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-09 17:46 UTC by Michal Linhard
Modified: 2023-05-15 19:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The startInterceptor method was called before it was initialized. When four nodes started, <literal>NullPointerException</literal> errors displayed. This is fixed so that the startInterceptor method is now called after it is initialized. As a result, when four nodes are now started, they operate as expected with no errors.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
config.zip (5.75 KB, application/zip)
2011-09-13 13:02 UTC, Michal Linhard
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 745913 0 high CLOSED hotrod server startup problem due to lock acquisition timeout 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker EDG-6 0 Major Closed NPE in CacheLoaderInterceptor 2016-03-24 18:16:01 UTC

Internal Links: 745913

Description Michal Linhard 2011-09-09 17:46:34 UTC
project_key: EDG

a NPE occurs on startup of 4 nodes
{code}
16:13:15,731 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (pool-5-thread-44) ISPN000136: Execution error: java.lang.NullPointerException
	at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:149) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:218) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:90) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:90) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:90) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:201) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT]
        ...
{code}

this is because the initialisation code:

{code}
   @Start(priority = 15)
   protected void startInterceptor() {
      loader = clm.getCacheLoader();
   }
{code}

happens after the causing call...

it's happening on test1
the tracelogs are quite big: http://www.qa.jboss.com/~mlinhard/run21.zip
(I'll try to keep them on this location as long as this JIRA is relevant)

Comment 1 Michal Linhard 2011-09-09 17:47:57 UTC
Link: Added: This issue relates to JBPAPP-6929


Comment 2 Michal Linhard 2011-09-10 07:32:23 UTC
I just spotted the same thing in logs for JBPAPP-7021, but the solution there seems to be about something different.

Comment 3 Michal Linhard 2011-09-10 07:33:46 UTC
versions:
EDG 6.0.0-SNAPSHOT last commit 6d655c86ba05fe2f6a9aba5d77835dfbcb0aae4b Author: Galder Zamarreño <galderz> Date:   Wed Aug 31 16:36:23 2011 +0000
Infinispan 5.1.0-SNAPSHOT last commit fc94449eec33469057614a13cbfe59e4f4e855fd Author: Michal Linhard <michal> Date:   Wed Sep 7 13:42:32 2011 +0200
AS 7.0.1.Final

Comment 4 Michal Linhard 2011-09-10 07:38:00 UTC
JBPAPP-7021 seems to be about a different NPE

Comment 5 Michal Linhard 2011-09-13 13:02:34 UTC
config.zip - contains configuration of the instances and prepare.sh script I use to create the four servers

Comment 6 Michal Linhard 2011-09-13 13:02:34 UTC
Attachment: Added: config.zip


Comment 7 Michal Linhard 2011-09-13 14:47:51 UTC
Link: Added: This issue depends ISPN-1384


Comment 8 Anne-Louise Tangring 2011-09-26 19:16:00 UTC
Docs QE Status: Removed: NEW 


Comment 9 Galder Zamarreño 2011-09-29 08:39:52 UTC
This should be solved in 5.1.0.ALPHA2, but state transfer code might not work fully right. Either build a snapshot from master or wait for BETA1 which should be out in Monday/Tuesday.

Comment 10 Misha H. Ali 2012-03-23 02:20:01 UTC
The technical_notes? flag indicates that this is a known issue. Please add summarized cause (what caused the issue) and consequence (how the issue manifests) information about this in the Technical Notes field.

Comment 11 Misha H. Ali 2012-03-27 00:17:37 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: The startInterceptor method is called before it is initialized.
Consequence: When four nodes are started, NullPointerException errors display.
Fix: The startInterceptor method is now called after it is initialized.
Result: When four nodes are started, they operate as expected with no errors.

Comment 12 Tristan Tarrant 2012-03-29 12:07:02 UTC
Does this still happen?

Comment 13 Michal Linhard 2012-03-29 12:31:08 UTC
No. And it hasn't for some time now. Sorry, I forgot about this one.

Comment 14 Misha H. Ali 2012-06-04 01:02:32 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1 @@
-Cause: The startInterceptor method is called before it is initialized.
+The startInterceptor method was called before it was initialized. When four nodes started, NullPointerException errors displayed. This is fixed so that the startInterceptor method is now called after it is initialized. As a result, when four nodes are now started, they operate as expected with no errors.-Consequence: When four nodes are started, NullPointerException errors display.
-Fix: The startInterceptor method is now called after it is initialized.
-Result: When four nodes are started, they operate as expected with no errors.

Comment 15 Misha H. Ali 2012-06-04 02:56:21 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-The startInterceptor method was called before it was initialized. When four nodes started, NullPointerException errors displayed. This is fixed so that the startInterceptor method is now called after it is initialized. As a result, when four nodes are now started, they operate as expected with no errors.+The startInterceptor method was called before it was initialized. When four nodes started, <literal>NullPointerException</literal> errors displayed. This is fixed so that the startInterceptor method is now called after it is initialized. As a result, when four nodes are now started, they operate as expected with no errors.


Note You need to log in before you can comment on or make changes to this bug.