13 Replies Latest reply on Nov 7, 2014 5:25 AM by paupac

    Nullpointer exception in LazyCachedNode since version 3.6.1.Final

    dev_java

      Hello!

       

      We are using Modeshape in a clustered configuration, where the workspaces, indexes and persistent caches are all configured in cluster mode.

      When trying to upgrade to Modeshape 3.6.1.Final (or any newer version), we get the following nullpointer exception.

       

      ERROR [org.modeshape.jcr.SystemNamespaceRegistry] [modeshape-start-repo-1-thread-1] <Node types were read from the system content, and appear to be inconsistent or invalid: content-repository>

      java.lang.NullPointerException

        at org.modeshape.jcr.cache.document.LazyCachedNode.properties(LazyCachedNode.java:254)

        at org.modeshape.jcr.cache.document.LazyCachedNode.getProperty(LazyCachedNode.java:378)

        at org.modeshape.jcr.SystemContent.first(SystemContent.java:647)

        at org.modeshape.jcr.SystemContent.first(SystemContent.java:641)

        at org.modeshape.jcr.SystemContent.readAllNamespaces(SystemContent.java:660)

        at org.modeshape.jcr.SystemNamespaceRegistry.refreshFromSystem(SystemNamespaceRegistry.java:83)

        at org.modeshape.jcr.JcrRepository$RunningState.<init>(JcrRepository.java:1122)

        at org.modeshape.jcr.JcrRepository$RunningState.<init>(JcrRepository.java:971)

        at org.modeshape.jcr.JcrRepository.doStart(JcrRepository.java:404)

        at org.modeshape.jcr.JcrRepository.start(JcrRepository.java:328)

        at org.modeshape.jcr.ModeShapeEngine$2.call(ModeShapeEngine.java:370)

        at org.modeshape.jcr.ModeShapeEngine$2.call(ModeShapeEngine.java:365)

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

        at java.util.concurrent.FutureTask.run(FutureTask.java:166)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

        at java.lang.Thread.run(Thread.java:724)

       

      The exception does not occur on the first cluster node that is started, but on any node that is started subsequently. The node with the exception then cannot read custom node types and namespaces and refuses to start. The change that introduced that nullpointer was made for MODE-2121.

      We suppose that the problem occurs because the LazyCachedNode is serialized over the workspace cache and on deserialization the 'properties' and 'parentRefToSelf' fields are not initialized and therefore null.

       

      Any help is appreciated!

       

      Best regards,

       

      Bernhard

        • 1. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
          hchiorean

          Hi,

           

          Have you tried this using the latest version - 3.7.1 ? If yes and you still have the same problem can you post your clustering configuration ? Thanks.

          • 2. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
            dev_java

            Hello!

             

            Yes, the problem occurs with all versions beyond 3.6.1.Final (tried 3.6.1.Final, 3.7.0.Final and 3.7.1.Final).

             

            The modeshape instances are running embedded in tomcat 7.0.47x64.

             

            Here is the configuration:

             

            Modeshape:

            ------------------------

            ...

                "workspaces" : {

                "predefined" : ["content"],

                    "default" : "content",

                    "allowCreation" : true,

                    "cacheConfiguration" : "infinispan-configuration-cluster.xml",

                },

            ...

              "clustering" : {

                    "clusterName" : "workspace-cluster",

                    "channelConfiguration" : "jgroups-udp.xml"

                },

            ...

             

            Infinispan (workspace caches use the 'default' configuration - no separate named caches are defined for these):

            ------------------------

            ...

              <default>

              <jmxStatistics enabled="true" />

              <clustering mode="replication">

              <sync />

              <stateTransfer fetchInMemoryState="true" />

              </clustering>

              </default>

            ...

             

            JGroups:

            ------------------------

            The JGroups configuration is the standard udp configuration that comes with infinispan 5.2.7.Final (jgroups-udp.xml).

             

            Best regards,

             

            Bernhard

            • 3. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
              hchiorean

              Workspace caches *should never be clustered*. They are only meant to be used as local, in process caches and 99% of the time the default configuration for them is enough (meaning you don't need to specify a config)

               

              What you should be doing is not configuring the workspace cache (inside the "workspaces" section) but the main ISPN cache like:

               

              "storage" : {

                      "cacheName" : you_should_name_your_cache_in_ISPN",

                      "cacheConfiguration" : ""infinispan-configuration-cluster.xml"

              ....

               

              Also, in a real cluster we recommend you explicitly define the locking & transactional behavior. For example: modeshape/modeshape-jcr/src/test/resources/config/clustered-repo-config-ispn.xml at modeshape-3.7.1.Final · ModeShape/mo…

              • 4. Re: Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                dev_java

                Hello!

                 

                Thank you for your quick and helpful reply. I have changed the configuration according to you suggestions and running the workspace caches in local mode indeed solved the former problem.

                I was not aware of the fact that the workspace caches must not be clustered.

                Unfortunately, now Modeshape has troubles updating the query indexes. I have configured the query engine to use the Modeshape internal eventing mechanism (as described here: https://issues.jboss.org/browse/MODE-1943), because I want the cluster nodes to be completely independent without a single point of failure (no master/slave).

                 

                Query configuration for event-based index updates:

                ---------------------------------------------------

                "query" : {

                        "enabled": true,

                        "indexing" : {

                            "rebuildOnStartup": {

                                "when": "always"

                            },

                            "backend" : {

                                "type" : "lucene",

                            }

                        },

                        "indexStorage" : {

                            "type" : "filesystem",

                            "location" : "${modeshape.query.indexStorage.location}",

                            "lockingStrategy" : "native",

                            "fileSystemAccessType" : "auto",

                        }

                    },

                 

                But now, if I save a content in cluster node A, then I immediately get errors like these in cluster node B:

                 

                ERROR [org.modeshape.jcr.cache.RepositoryCache] - <Error updating the query indexes: Cannot locate child node: 24ab7a7317f1e73a432a60-0433-44cb-addf-7bcc32e17b94 within parent: 24ab7a7317f1e7504fac73-f703-4459-aab4-10c6045ce4b0>

                org.modeshape.jcr.cache.NodeNotFoundInParentException: Cannot locate child node: 24ab7a7317f1e73a432a60-0433-44cb-addf-7bcc32e17b94 within parent: 24ab7a7317f1e7504fac73-f703-4459-aab4-10c6045ce4b0

                  at org.modeshape.jcr.cache.document.LazyCachedNode.parentReferenceToSelf(LazyCachedNode.java:250)

                  at org.modeshape.jcr.cache.document.LazyCachedNode.getSegment(LazyCachedNode.java:287)

                  at org.modeshape.jcr.cache.document.LazyCachedNode.getPath(LazyCachedNode.java:296)

                  at org.modeshape.jcr.cache.RepositoryCache$LocalChangeListener.updateIndexesForRemoteEvent(RepositoryCache.java:749)

                  at org.modeshape.jcr.cache.RepositoryCache$LocalChangeListener.notify(RepositoryCache.java:683)

                  at org.modeshape.jcr.bus.RepositoryChangeBus.submitChanges(RepositoryChangeBus.java:187)

                  at org.modeshape.jcr.bus.RepositoryChangeBus.notify(RepositoryChangeBus.java:175)

                  at org.modeshape.jcr.bus.ClusteredRepositoryChangeBus$Receiver.receive(ClusteredRepositoryChangeBus.java:311)

                  at org.jgroups.JChannel.invokeCallback(JChannel.java:749)

                  at org.jgroups.JChannel.up(JChannel.java:710)

                  at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1025)

                  at org.jgroups.protocols.RSVP.up(RSVP.java:188)

                  at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)

                  at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)

                  at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)

                  at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)

                  at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)

                  at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:453)

                  at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:763)

                  at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)

                  at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)

                  at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)

                  at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)

                  at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)

                  at org.jgroups.protocols.Discovery.up(Discovery.java:359)

                  at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)

                  at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)

                  at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1793)

                  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

                  at java.lang.Thread.run(Thread.java:724)

                 

                ERROR [org.modeshape.jcr.cache.RepositoryCache] - <Error updating the query indexes: Cannot locate child node: 24ab7a7040f06f504fac73-f703-4459-aab4-10c6045ce4b0 within parent: 24ab7a7040f06f125a8fd9-d8ae-4409-b3ab-20d06cc13b96>

                org.modeshape.jcr.cache.NodeNotFoundInParentException: Cannot locate child node: 24ab7a7040f06f504fac73-f703-4459-aab4-10c6045ce4b0 within parent: 24ab7a7040f06f125a8fd9-d8ae-4409-b3ab-20d06cc13b96

                  at org.modeshape.jcr.cache.document.LazyCachedNode.parentReferenceToSelf(LazyCachedNode.java:250)

                  at org.modeshape.jcr.cache.document.LazyCachedNode.getSegment(LazyCachedNode.java:287)

                  at org.modeshape.jcr.cache.document.LazyCachedNode.getPath(LazyCachedNode.java:296)

                  at org.modeshape.jcr.cache.RepositoryCache$LocalChangeListener.updateIndexesForRemoteEvent(RepositoryCache.java:760)

                  at org.modeshape.jcr.cache.RepositoryCache$LocalChangeListener.notify(RepositoryCache.java:683)

                  at org.modeshape.jcr.bus.RepositoryChangeBus$ChangeSetDispatcher.call(RepositoryChangeBus.java:227)

                  at org.modeshape.jcr.bus.RepositoryChangeBus$ChangeSetDispatcher.call(RepositoryChangeBus.java:209)

                  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

                  at java.util.concurrent.FutureTask.run(FutureTask.java:166)

                  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

                  at java.lang.Thread.run(Thread.java:724)

                 

                Do you have any idea or hint what could be wrong here?

                 

                Thanks in advance,

                 

                Bernhard

                • 5. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                  rhauch

                  Please be clear that there are two kinds of caches: the main repository cache is referenced from within the "storage/cacheConfiguration" portion of the ModeShape configuration file, and repository caches must always be clustered. The value of this configuration property should refer to the location of an Infinispan configuration file that (if you're clustering your processes) should use clustering with either replicated (suggested), invalidation, or distributed mode. This Infinispan cache stores all content for all workspaces inside the repository.

                   

                  Every process also has its own internal in-memory, non-persistent, local transient "workspace cache" that is defined by the "workspace/cacheConfiguration" portion of the configuration file. This is used by ModeShape literally as a cache, and this must never be clustered. The value of this configuration property should refer to a separate Infinispan configuration file, but by default it points to the "org/modeshape/jcr/default-workspace-cache-config.xml" file that is included in the modeshape-jcr-<version>.jar file and on the classpath.

                   

                  Whenever we say "workspace cache", we are always referring to the latter cache.

                  • 6. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                    hchiorean

                    The exception that you're seeing now seems to indicate that the ModeShape instances are clustered (indexes are being updated across the cluster) but the ISPN caches are not correctly clustered and state transfer isn't happening correctly.

                     

                    Have a look at modeshape/modeshape-jcr/src/test/resources/config/clustered-repo-config-ispn.xml at modeshape-3.7.1.Final · ModeShape/mo… for an example of how an ISPN replicated cache cluster config file.

                    • 7. Re: Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                      dev_java

                      Hello!

                       

                      First I would like to thank Randall for the clarification on the caches and Horia for pointing out that the cluster config might be the reason for the exceptions.

                      I have made some further investigations on the topic and noticed, that these exceptions only occur after a store is configured for the persistent Modeshape cache.

                      I have tried different configurations and came up with the following intermediate results:

                       

                      Modeshape storage configuration:

                      ...

                      "storage" : {

                        "cacheName" : "STORE_STRING",

                        "cacheConfiguration" : "infinispan-configuration-cluster.xml",

                        "binaryStorage" : {

                        "type" : "cache",

                        "storeName" : "binary-store",

                        "dataCacheName" : "STORE_BINARY",

                        "metadataCacheName" : "STORE_BINARY_META",

                        "cacheConfiguration" : "infinispan-configuration-cluster.xml",

                        "minimumBinarySizeInBytes" : 4096,

                        "minimumStringSize" : 4096,

                        "chunkSize" : 1048576

                        }

                      }

                      ...

                       

                      Infinispan configuration:

                       

                      Index update exceptions occurring:

                      ...

                      <namedCache name="STORE_STRING">

                        <jmxStatistics enabled="true" />

                        <clustering mode="replication">

                        <sync/>

                        <stateTransfer chunkSize="100" fetchInMemoryState="true" />

                        </clustering>

                        <loaders passivation="false" shared="true" preload="false">

                        <jdbc:stringKeyedJdbcStore fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false" >

                        <jdbc:dataSource jndiUrl="java:comp/env/jdbc/oracle" />

                        <jdbc:stringKeyedTable dropOnExit="false" createOnStart="true" prefix="INF">

                        <jdbc:idColumn name="ID_COLUMN" type="VARCHAR(255)" />

                        <jdbc:dataColumn name="DATA_COLUMN" type="BLOB" />

                        <jdbc:timestampColumn name="TIMESTAMP_COLUMN" type="NUMBER(32)" />

                        </jdbc:stringKeyedTable>

                        </jdbc:stringKeyedJdbcStore>

                        </loaders>

                        <transaction transactionMode="TRANSACTIONAL" lockingMode="PESSIMISTIC" cacheStopTimeout="180000"/>

                      </namedCache>

                      ...

                       

                      No index update exceptions occurring:

                      ...

                      <namedCache name="STORE_STRING">

                        <jmxStatistics enabled="true" />

                        <clustering mode="replication">

                        <sync/>

                        <stateTransfer chunkSize="100" fetchInMemoryState="true" />

                        </clustering>

                        <transaction transactionMode="TRANSACTIONAL" lockingMode="PESSIMISTIC" cacheStopTimeout="180000"/>

                      </namedCache>

                      ...

                       

                      I was not able to figure out yet how the loader configuration for persisting cache data can lead to the index update exceptions.

                      As long as the jdbc store is not in the configuration everything seems to work as expected (besides the missing persistence).

                      Can you provide any further hints what might be going wrong behind the scenes and what I could check / try to fix that problem?

                       

                      Thanks in advance!

                       

                      Best regards,

                       

                      Bernhard

                       

                      EDIT: I have furthermore noticed that the exception only occurs with PESSIMISTIC locking.

                      • 8. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                        paupac

                        Hi Bernhard,

                        how did this end? I'm trying a similar configuration with Oracle 12c, two nodes with ModeShape 3.8.0 Final and I'm seeing the index update exceptions when the load is

                        heavy (using a Jmeter script with 100 threads).

                        Have you succeeded in making it work by using a relational-database persistent cache store?

                         

                        Thanks,

                         

                        regards,

                         

                        Pau

                        • 9. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                          dev_java

                          Hello Pau,

                           

                          well, i didn't find any real answers to the problem. What i did in the end was Upgrade to MS4 which seems to handle clustering and Index updates ways better than Version 3 did (at least with the current local index provider).

                          I don't know your current configuration but one thing that caused additional problems in that case was that the binary and binary-metadata stores were also configured as transactional. Making only the string-store transactional also helped improving the situation so you could try that (in case those caches are transactional at the moment in your configuration).

                           

                          Regards,

                           

                          Bernhard

                          • 10. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                            hchiorean

                            I'm trying a similar configuration with Oracle 12c, two nodes with ModeShape 3.8.0 Final and I'm seeing the index update exceptions when the load is

                             

                            If you can't move to 4.0, try using 3.8.1.Final and see if that makes a difference. Some other points that may be relevant:

                            • 11. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                              paupac

                              Hi,

                              I have tried configuring the binary and binary metadata caches as non-transactional with no changes. Errors appear sooner or later. Typically after 3 hours of continued heavy use (100 threads when load testing with JMeter).

                              • I'm using an embedded version of ModeShape, it is embedded in a webapp that can be executed in any application server, tests are done with Tomcat (TomEE).
                              • transactions are controlled inside of ModeShape
                              • I do have eviction and I have seen in my latest test the error you mention.
                              • I will try MS 3.8.1 Final although when we tried this version we saw more crashes -under normal use, not heavy use- than with 3.8.0 Final. I cannot move to MS 4 at this time but I may be able to in the future.
                              • Here follows my last configuration just in case it might be useful to someone who is using Oracle and clustering.

                              modeshape_config.json:

                              {

                                  "name" : "mpw.repository",

                                  "jndiName" : "",

                                  "transactionMode" : "auto",

                                  "storage" : {

                                      "cacheName" : "mpw.cache",

                                      "cacheConfiguration" : "mpw/infinispan_config.xml",

                                      "binaryStorage" : {

                                          "type" : "cache",

                                          "dataCacheName" : "mpw.data_cache",

                                          "metadataCacheName" : "mpw.metadata_cache"

                                      }

                                  },

                                  "monitoring" : {

                                      "enabled" : false

                                  },

                                  "security" : {

                                      "anonymous" : {

                                          "username" : "<anonymous>",

                                          "roles" : [],

                                          "useOnFailedLogin" : false

                                      },

                                      "providers" : [

                                          { "classname" : "com....AuthenticationProvider" }

                                      ]

                                  },

                                  "query" : {

                                      "indexStorage" : {

                                          "type" : "filesystem",

                                          "location" : "mpw/index",

                                "lockingStrategy":"simple",

                                          "fileSystemAccessType":"auto"

                                      }

                                  },

                                "clustering" : {

                                "clusterName" : "mpw-modeshape-cluster",

                                "channelConfiguration" : "tcp.xml"

                                }

                              }

                               

                              infinispan_config.xml:

                              <infinispan

                                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                                      xsi:schemaLocation="urn:infinispan:config:5.2      http://www.infinispan.org/schemas/infinispan-config-5.2.xsd

                                                          urn:infinispan:config:jdbc:5.2 http://www.infinispan.org/schemas/infinispan-cachestore-jdbc-config-5.2.xsd"

                                      xmlns="urn:infinispan:config:5.2">

                                  <global>

                                      <!-- Defines the global settings shared by all caches -->

                                      <globalJmxStatistics enabled="false" allowDuplicateDomains="true"/>

                                      <shutdown hookBehavior="REGISTER" />

                                <transport clusterName="mpw-infinispan-cluster">

                                <properties>

                                <property name="configurationFile" value="tcp.xml" />

                                </properties>

                                </transport>

                                  </global>

                               

                               

                                  <!--

                                  Defines the default behavior for all caches, including those created dynamically (e.g., when a

                                  repository uses a cache that doesn't exist in this configuration).

                                  -->

                                  <default/>

                               

                               

                               

                               

                                  <!-- Repository store -->

                               

                                  <namedCache name="mpw.cache">

                                <clustering mode="replication">

                                <sync />

                                </clustering>

                                      <!-- The original GenericTransactionManagerLookup did not work for Websphere 8. -->

                                      <transaction transactionManagerLookupClass="com.....CustomGenericTransactionManagerLookup"

                                                   transactionMode="TRANSACTIONAL" lockingMode="PESSIMISTIC"/>

                               

                               

                                      <eviction maxEntries="1000" strategy="LIRS"/>

                                      <!--<deadlockDetection enabled="true" spinDuration="1000"/>-->

                                     <locking useLockStriping="false" lockAcquisitionTimeout="15000"/> <!--concurrencylevel="150" -->

                               

                               

                                      <!--

                                      Define the cache loaders (i.e., cache stores). Passivation is false because we want *all*

                                      data to be persisted, not just what doesn't fit into memory. Shared is false because there

                                      are no other caches sharing this file store. We set preload to false for lazy loading;

                                      may be improved by preloading and configuring eviction.

                                      We can have multiple cache loaders, which get chained. But we'll define just one.

                                      -->

                                      <loaders passivation="false" shared="true" preload="false">

                                          <stringKeyedJdbcStore xmlns="urn:infinispan:config:jdbc:5.2" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false">

                                              <connectionPool connectionUrl="jdbc:oracle:thin:@...:1521:ORCL" username="c##ISPN_USER" password="..." driverClass="oracle.jdbc.OracleDriver"/>          

                                <stringKeyedTable dropOnExit="false" createOnStart="true" prefix="ISPN">

                                <idColumn name="ID_COLUMN" type="VARCHAR2(500)"/>

                                <dataColumn name="DATA_COLUMN" type="BLOB"/>

                                <timestampColumn name="TIMESTAMP_COLUMN" type="NUMBER(19)"/>

                                </stringKeyedTable>

                                          </stringKeyedJdbcStore>

                                      </loaders>

                                  </namedCache>

                               

                               

                                  <!-- binary store -->

                                  <namedCache name="mpw.data_cache">

                                <clustering mode="replication">

                                <sync />

                                </clustering>

                                      <transaction transactionManagerLookupClass="com...CustomGenericTransactionManagerLookup"

                                                   transactionMode="NON_TRANSACTIONAL" lockingMode="PESSIMISTIC"/>

                                <eviction maxEntries="1000" strategy="LIRS"/>

                                     <locking useLockStriping="false" lockAcquisitionTimeout="15000" />

                                      <loaders passivation="false" shared="true" preload="false">

                                          <stringKeyedJdbcStore xmlns="urn:infinispan:config:jdbc:5.2" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false">

                                              <connectionPool connectionUrl="jdbc:oracle:thin:@...:1521:ORCL" username="c##ISPN_USER" password="..." driverClass="oracle.jdbc.OracleDriver"/>          

                                <stringKeyedTable dropOnExit="false" createOnStart="true" prefix="ISPN">

                                <idColumn name="ID_COLUMN" type="VARCHAR2(500)"/>

                                <dataColumn name="DATA_COLUMN" type="BLOB"/>

                                <timestampColumn name="TIMESTAMP_COLUMN" type="NUMBER(19)"/>

                                </stringKeyedTable>

                                          </stringKeyedJdbcStore>

                                      </loaders>

                                  </namedCache>

                               

                               

                                  <!-- binary metadata store -->

                                  <namedCache name="mpw.metadata_cache">

                                <clustering mode="replication">

                                <sync />

                                </clustering>

                                  <transaction transactionManagerLookupClass="com...CustomGenericTransactionManagerLookup"

                                               transactionMode="NON_TRANSACTIONAL" lockingMode="PESSIMISTIC"/>

                                <eviction maxEntries="1000" strategy="LIRS"/>

                                     <locking useLockStriping="false" lockAcquisitionTimeout="15000" />

                                      <loaders passivation="false" shared="true" preload="false">

                                          <stringKeyedJdbcStore xmlns="urn:infinispan:config:jdbc:5.2" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false">

                                              <connectionPool connectionUrl="jdbc:oracle:thin:@...:1521:ORCL" username="c##ISPN_USER" password="..." driverClass="oracle.jdbc.OracleDriver"/>          

                                <stringKeyedTable dropOnExit="false" createOnStart="true" prefix="ISPN">

                                <idColumn name="ID_COLUMN" type="VARCHAR2(500)"/>

                                <dataColumn name="DATA_COLUMN" type="BLOB"/>

                                <timestampColumn name="TIMESTAMP_COLUMN" type="NUMBER(19)"/>

                                </stringKeyedTable>

                                          </stringKeyedJdbcStore>

                                      </loaders>

                                  </namedCache>

                               

                               

                              </infinispan> 

                               

                              Note that transactionMode for the last two caches is NON_TRANSACTIONAL although in every test but the last one the value was TRANSACTIONAL.

                               

                              Thanks and regards,

                               

                               

                              pau

                              • 12. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                                hchiorean

                                Are you only seeing the exception for the indexing thread or are you getting the exception for the main application thread as well ? (similar to the first post from this thread)

                                EDIT: if the exception is only indexing related, it means some indexing events are out-of-bounds with regards to the data that's persisted in the cache. Can you check if the same problem occurs with just 1 node (i.e. non clustered setup) ?

                                • 13. Re: Nullpointer exception in LazyCachedNode since version 3.6.1.Final
                                  paupac

                                  The javax.jcr.PathNotFoundException was seen in the main application thread only.

                                  By the way I can only send one message per hour. So my replies will be slower than they would be.

                                  EDIT: there are no errors with just one node, even under heavy load.