[JBoss JIRA] (ISPN-6534) REST endpoint page doesn't work
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6534?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-6534:
---------------------------------------
Caused by removing Undertow dependency from ISPN in [e81d358351d|https://github.com/infinispan/infinispan/commit/e81d358351d5a...] - not sure if it worth to implement http server for one single html page
> REST endpoint page doesn't work
> -------------------------------
>
> Key: ISPN-6534
> URL: https://issues.jboss.org/browse/ISPN-6534
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.1.Final
> Reporter: Roman Macor
>
> - start infinispan standalone server
> - in web browser go to localhost:8080
> Result:
> Nothing is displayed in the browser
> Server log:
> 12:58:55,882 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (nioEventLoopGroup-7-1) RESTEASY002010: Failed to execute: javax.ws.rs.NotFoundException: RESTEASY003210: Could not find resource for full path: http://localhost:8080/
> at org.jboss.resteasy.core.registry.ClassNode.match(ClassNode.java:75)
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:445)
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:257)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:194)
> at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
> at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:53)
> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
> at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
> at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
> at java.lang.Thread.run(Thread.java:745)
> Expected result:
> Rest console should be displayed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 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:
----------------------------------
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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 months