[JBoss JIRA] (ISPN-6071) NullPointerException when executing RemoveExpiredCommand
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6071?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6071:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> NullPointerException when executing RemoveExpiredCommand
> --------------------------------------------------------
>
> Key: ISPN-6071
> URL: https://issues.jboss.org/browse/ISPN-6071
> Project: Infinispan
> Issue Type: Bug
> Components: Expiration
> Affects Versions: 8.0.2.Final
> Reporter: Jason Hoetger
> Assignee: William Burns
> Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final
>
>
> I'm running Infinispan 8.0.2 in a clustered environment with a replicated cache with a single file cache store. I'm seeing some NullPointerExceptions when Infinispan executes the RemoveExpiredCommand. Here's a snippet from the stack trace:
> {noformat}
> ISPN000136: Error executing command RemoveExpiredCommand, writing keys [...large key here...]
> ...
> Caused by: java.lang.NullPointerException: null
> at org.infinispan.commands.write.RemoveExpiredCommand.setParameters(RemoveExpiredCommand.java:142)
> {noformat}
> Here's RemoveExpiredCommand#setParameters(...):
> {code} @Override
> public void setParameters(int commandId, Object[] args) {
> if (commandId != COMMAND_ID) throw new IllegalStateException("Invalid method id");
> int i = 0;
> commandInvocationId = (CommandInvocationId) args[i++];
> key = args[i++];
> value = args[i++];
> lifespan = (long) args[i++];
> }{code}
> Line 142 is the cast of assignment of {{args\[3\]}} to primitive type long, which is causing the NPE. lifespan is actually a Long, not a long, and the {{perform()}} method seems to anticipate null lifespans at line 72:
> {code} // If the provided lifespan is null, that means it is a store removal command, so we can't compare lifespan
> if (lifespan == null) {}{code}
> Could this be fixed by simply changing the cast at line 142 from (long) to (Long)?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6071) NullPointerException when executing RemoveExpiredCommand
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6071?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6071:
----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4160, https://github.com/infinispan/infinispan/pull/4292 (was: https://github.com/infinispan/infinispan/pull/4160)
> NullPointerException when executing RemoveExpiredCommand
> --------------------------------------------------------
>
> Key: ISPN-6071
> URL: https://issues.jboss.org/browse/ISPN-6071
> Project: Infinispan
> Issue Type: Bug
> Components: Expiration
> Affects Versions: 8.0.2.Final
> Reporter: Jason Hoetger
> Assignee: William Burns
> Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final
>
>
> I'm running Infinispan 8.0.2 in a clustered environment with a replicated cache with a single file cache store. I'm seeing some NullPointerExceptions when Infinispan executes the RemoveExpiredCommand. Here's a snippet from the stack trace:
> {noformat}
> ISPN000136: Error executing command RemoveExpiredCommand, writing keys [...large key here...]
> ...
> Caused by: java.lang.NullPointerException: null
> at org.infinispan.commands.write.RemoveExpiredCommand.setParameters(RemoveExpiredCommand.java:142)
> {noformat}
> Here's RemoveExpiredCommand#setParameters(...):
> {code} @Override
> public void setParameters(int commandId, Object[] args) {
> if (commandId != COMMAND_ID) throw new IllegalStateException("Invalid method id");
> int i = 0;
> commandInvocationId = (CommandInvocationId) args[i++];
> key = args[i++];
> value = args[i++];
> lifespan = (long) args[i++];
> }{code}
> Line 142 is the cast of assignment of {{args\[3\]}} to primitive type long, which is causing the NPE. lifespan is actually a Long, not a long, and the {{perform()}} method seems to anticipate null lifespans at line 72:
> {code} // If the provided lifespan is null, that means it is a store removal command, so we can't compare lifespan
> if (lifespan == null) {}{code}
> Could this be fixed by simply changing the cast at line 142 from (long) to (Long)?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6574:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4291
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 9.0.0.Final
>
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6574:
-----------------------------------
Affects Version/s: 9.0.0.Alpha1
8.2.1.Final
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 9.0.0.Final
>
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6574:
-----------------------------------
Component/s: JCache
Fix Version/s: 9.0.0.Alpha2
9.0.0.Final
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 9.0.0.Final
>
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6577) Cache configuration ignored when configured with "configuration" element
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6577?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-6577:
-----------------------------------------
[~NadirX] It could or maybe it is related to https://github.com/infinispan/infinispan/pull/4271#discussion_r61146194 where it is picking the default cache configuration instead
> Cache configuration ignored when configured with "configuration" element
> ------------------------------------------------------------------------
>
> Key: ISPN-6577
> URL: https://issues.jboss.org/browse/ISPN-6577
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Tristan Tarrant
> Priority: Critical
>
> Given the following config:
> {code:xml}
> <replicated-cache-configuration name="indexed-cache" mode="SYNC" start="EAGER" remote-timeout="20000"/>
> <replicated-cache name="booksCache" configuration="indexed-cache">
> <indexing index="LOCAL">
> <property name="default.metadata_cachename">indexMetadataBooksCache</property>
> <property name="default.data_cachename">indexDataBooksCache</property>
> <property name="default.locking_cachename">indexLockingBooksCache</property>
> <property name="default.directory_provider">infinispan</property>
> <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager</property>
> <property name="lucene_version">LUCENE_CURRENT</property>
> </indexing>
> </replicated-cache>
> {code}
> The booksCache starts in non-indexed mode, even if it explicitly configure the indexing
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6577) Cache configuration ignored when configured with "configuration" element
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6577?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-6577:
-------------------------------------
Assignee: Tristan Tarrant
> Cache configuration ignored when configured with "configuration" element
> ------------------------------------------------------------------------
>
> Key: ISPN-6577
> URL: https://issues.jboss.org/browse/ISPN-6577
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Tristan Tarrant
> Priority: Critical
>
> Given the following config:
> {code:xml}
> <replicated-cache-configuration name="indexed-cache" mode="SYNC" start="EAGER" remote-timeout="20000"/>
> <replicated-cache name="booksCache" configuration="indexed-cache">
> <indexing index="LOCAL">
> <property name="default.metadata_cachename">indexMetadataBooksCache</property>
> <property name="default.data_cachename">indexDataBooksCache</property>
> <property name="default.locking_cachename">indexLockingBooksCache</property>
> <property name="default.directory_provider">infinispan</property>
> <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager</property>
> <property name="lucene_version">LUCENE_CURRENT</property>
> </indexing>
> </replicated-cache>
> {code}
> The booksCache starts in non-indexed mode, even if it explicitly configure the indexing
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6577) Cache configuration ignored when configured with "configuration" element
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6577?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-6577:
---------------------------------------
Could it be that it is not inheriting the properties ?
> Cache configuration ignored when configured with "configuration" element
> ------------------------------------------------------------------------
>
> Key: ISPN-6577
> URL: https://issues.jboss.org/browse/ISPN-6577
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Gustavo Fernandes
> Priority: Critical
>
> Given the following config:
> {code:xml}
> <replicated-cache-configuration name="indexed-cache" mode="SYNC" start="EAGER" remote-timeout="20000"/>
> <replicated-cache name="booksCache" configuration="indexed-cache">
> <indexing index="LOCAL">
> <property name="default.metadata_cachename">indexMetadataBooksCache</property>
> <property name="default.data_cachename">indexDataBooksCache</property>
> <property name="default.locking_cachename">indexLockingBooksCache</property>
> <property name="default.directory_provider">infinispan</property>
> <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager</property>
> <property name="lucene_version">LUCENE_CURRENT</property>
> </indexing>
> </replicated-cache>
> {code}
> The booksCache starts in non-indexed mode, even if it explicitly configure the indexing
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ISPN-6578) Add named param perf test
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6578?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6578:
--------------------------------
Description: Measure how much it takes to parse a jpql query and transform it into Lucene. Compare first and further attempts. Compare timings with 8.2.x branch.
> Add named param perf test
> -------------------------
>
> Key: ISPN-6578
> URL: https://issues.jboss.org/browse/ISPN-6578
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.0.0.Alpha2, 8.2.2.Final
>
>
> Measure how much it takes to parse a jpql query and transform it into Lucene. Compare first and further attempts. Compare timings with 8.2.x branch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months