[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7572?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-7572:
----------------------------------
Status: Open (was: New)
> Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-7572
> URL: https://issues.jboss.org/browse/ISPN-7572
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Lucene Directory, WildFly modules
> Affects Versions: 9.0.0.CR2, 8.2.6.Final
> Reporter: Sanne Grinovero
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 9.0.0.Final, 8.2.7.Final
>
>
> When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL).
> In this case if the configuration file refers to any extension such as a {{CacheStore}}, Infinispan will fail to start as it doesn't depend on the modules of its extensions.
> This will cause puzzling errors such as :
> {{ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.}}
> For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past:
> Explicit classloader support during parsing was introduced in 2013:
> - http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html
> Then removed again in 2014:
> - http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html
> I asked for improvements and hoped for someone to take ownership:
> - http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html
> In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did.
> Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL.
> My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them.
> In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them.
> But [~NadirX] doesn't like that, so assigning the issue to him ;-)
> Alternative ideas:
> * allow people to mention module names explicitly in the Infinispan configuration?
> * have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI
> I favour the second option, especially as it came up before as a dire pratical need for many other situations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-7572:
-------------------------------------
Summary: Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
Key: ISPN-7572
URL: https://issues.jboss.org/browse/ISPN-7572
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores, Lucene Directory, WildFly modules
Affects Versions: 8.2.6.Final, 9.0.0.CR2
Reporter: Sanne Grinovero
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 9.0.0.Final, 8.2.7.Final
When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL).
In this case if the configuration file refers to any extension such as a {{CacheStore}}, Infinispan will fail to start as it doesn't depend on the modules of its extensions.
This will cause puzzling errors such as :
{{ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.}}
For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past:
Explicit classloader support during parsing was introduced in 2013:
- http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html
Then removed again in 2014:
- http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html
I asked for improvements and hoped for someone to take ownership:
- http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html
In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did.
Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL.
My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them.
In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them.
But [~NadirX] doesn't like that, so assigning the issue to him ;-)
Alternative ideas:
* allow people to mention module names explicitly in the Infinispan configuration?
* have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI
I favour the second option, especially as it came up before as a dire pratical need for many other situations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-6993) TimeoutException: Replication timeout when handling request with DIST cache
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6993?page=com.atlassian.jira.plugin.... ]
Dan Berindei closed ISPN-6993.
------------------------------
Resolution: Duplicate Issue
Duplicate of ISPN-6992
> TimeoutException: Replication timeout when handling request with DIST cache
> ---------------------------------------------------------------------------
>
> Key: ISPN-6993
> URL: https://issues.jboss.org/browse/ISPN-6993
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.4.Final
> Environment: two data owners ,three node
> Reporter: yingming jiang
> Priority: Blocker
>
> 8.2.4 distributed-cache when the node members more than data owners ,raise time out exception
> my config as follow:
> infinispan.xml
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:8.2 http://www.infinispan.org/schemas/infinispan-config-8.2.xsd"
> xmlns="urn:infinispan:config:8.2">
> <jgroups>
> <stack-file name="tcp" path="jgroups-my.xml" />
> </jgroups>
> <cache-container default-cache="default">
> <transport stack="tcp" />
> <distributed-cache name="links">
> </distributed-cache>
> </cache-container>
> </infinispan>
> jgroups-my.xml
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups-3.6.xsd">
> <TCP bind_addr="${jgroups.tcp.address:127.0.0.1}"
> bind_port="${jgroups.tcp.port:7800}"
> recv_buf_size="${tcp.recv_buf_size:20M}"
> send_buf_size="${tcp.send_buf_size:2M}"
> sock_conn_timeout="300"/>
> <TCPGOSSIP initial_hosts="${jgroups.tcpgossip.initial_hosts}"/>
> <MERGE3/>
> <FD/>
> <VERIFY_SUSPECT/>
> <pbcast.NAKACK2 use_mcast_xmit="false"/>
> <UNICAST3/>
> <pbcast.STABLE/>
> <pbcast.GMS/>
> <MFC/>
> <FRAG2/>
> </config>
> error message:
> 2016-09-01 11:16:35,380 ERROR [InvocationContextInterceptor] (main) ISPN000136: Error executing command GetKeyValueCommand, writing keys []
> org.infinispan.util.concurrent.TimeoutException: Replication timeout for sptn-win-63-48742
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.staggeredProcessNext(CommandAwareRpcDispatcher.java:375)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$processCallsStaggered$3(CommandAwareRpcDispatcher.java:357)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Exception in thread "main" org.infinispan.util.concurrent.TimeoutException: Replication timeout for sptn-win-63-48742
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.staggeredProcessNext(CommandAwareRpcDispatcher.java:375)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$processCallsStaggered$3(CommandAwareRpcDispatcher.java:357)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> the bug is the same as follow ,the issue is gone when using -Dinfinispan.stagger.delay=0
> https://issues.jboss.org/browse/WFLY-6926
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7527) Local write skew check cannot work with persistence
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7527?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7527:
------------------------------
Status: Open (was: New)
> Local write skew check cannot work with persistence
> ---------------------------------------------------
>
> Key: ISPN-7527
> URL: https://issues.jboss.org/browse/ISPN-7527
> Project: Infinispan
> Issue Type: Bug
> Reporter: Radim Vansa
> Fix For: 9.0.0.CR3
>
>
> The local write skew check is not based on comparing versions but object refences in container. If the entry is evicted/passivated during a transaction, the reference is removed from container and write skew check throws exception. Loading from persistence layer is insufficient as we load a copy of the instance.
> Good thing is this may cause false negatives (spurious failures), but does not affect consistency.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7527) Local write skew check cannot work with persistence
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7527?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7527:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR3
Assignee: Radim Vansa
Resolution: Done
> Local write skew check cannot work with persistence
> ---------------------------------------------------
>
> Key: ISPN-7527
> URL: https://issues.jboss.org/browse/ISPN-7527
> Project: Infinispan
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.0.0.CR3
>
>
> The local write skew check is not based on comparing versions but object refences in container. If the entry is evicted/passivated during a transaction, the reference is removed from container and write skew check throws exception. Loading from persistence layer is insufficient as we load a copy of the instance.
> Good thing is this may cause false negatives (spurious failures), but does not affect consistency.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7500) ClusterListenerDistInitialStateTest emits NPE warning
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7500?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-7500:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Duplicate Issue
Being fixed in ISPN-6971
> ClusterListenerDistInitialStateTest emits NPE warning
> -----------------------------------------------------
>
> Key: ISPN-7500
> URL: https://issues.jboss.org/browse/ISPN-7500
> Project: Infinispan
> Issue Type: Bug
> Reporter: Sebastian Łaskawiec
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Final
>
>
> When executing {{ClusterListenerDistInitialStateTest}} one can see the following warning in the logs:
> {code}
> Transport protocol stack used = tcp
> 10:34:56,431 ERROR (remote-thread-ClusterListenerDistInitialStateTest-NodeB-p10-t6) [RpcManagerImpl] ISPN000073: Unexpected error while replicating
> java.lang.NullPointerException
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendTo(JGroupsTransport.java:724)
> at org.infinispan.remoting.rpc.RpcManagerImpl.sendTo(RpcManagerImpl.java:254)
> at org.infinispan.interceptors.TriangleAckInterceptor.sendExceptionAck(TriangleAckInterceptor.java:266)
> at org.infinispan.interceptors.TriangleAckInterceptor.onRemotePrimaryOwner(TriangleAckInterceptor.java:158)
> at org.infinispan.interceptors.InvocationFinallyAction.apply(InvocationFinallyAction.java:18)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
> at org.infinispan.interceptors.InvocationStage.andFinally(InvocationStage.java:39)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:160)
> at org.infinispan.interceptors.TriangleAckInterceptor.handleWriteCommand(TriangleAckInterceptor.java:147)10:34:56,437 ERROR (remote-thread-ClusterListenerDistInitialStateTest-NodeB-p10-t6) [RpcManagerImpl] ISPN000073: Unexpected error while replicating
> java.lang.NullPointerException
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendTo(JGroupsTransport.java:724)
> at org.infinispan.remoting.rpc.RpcManagerImpl.sendTo(RpcManagerImpl.java:254)
> at org.infinispan.interceptors.TriangleAckInterceptor.sendExceptionAck(TriangleAckInterceptor.java:266)
> at org.infinispan.interceptors.TriangleAckInterceptor.onRemotePrimaryOwner(TriangleAckInterceptor.java:158)
> at org.infinispan.interceptors.InvocationFinallyAction.apply(InvocationFinallyAction.java:18)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
> at org.infinispan.interceptors.InvocationStage.andFinally(InvocationStage.java:39)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:160)
> at org.infinispan.interceptors.TriangleAckInterceptor.handleWriteCommand(TriangleAckInterceptor.java:147)10:35:12,455 ERROR (remote-thread-ClusterListenerDistInitialStateTest-NodeDH-p890-t6) [RpcManagerImpl] ISPN000073: Unexpected error while replicating
> java.lang.NullPointerException
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendTo(JGroupsTransport.java:724)
> at org.infinispan.remoting.rpc.RpcManagerImpl.sendTo(RpcManagerImpl.java:254)
> at org.infinispan.interceptors.TriangleAckInterceptor.sendExceptionAck(TriangleAckInterceptor.java:266)
> at org.infinispan.interceptors.TriangleAckInterceptor.onRemotePrimaryOwner(TriangleAckInterceptor.java:158)
> at org.infinispan.interceptors.InvocationFinallyAction.apply(InvocationFinallyAction.java:18)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
> at org.infinispan.interceptors.InvocationStage.andFinally(InvocationStage.java:39)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:160)
> at org.infinispan.interceptors.TriangleAckInterceptor.handleWriteCommand(TriangleAckInterceptor.java:147)10:35:12,456 ERROR (remote-thread-ClusterListenerDistInitialStateTest-NodeDH-p890-t6) [RpcManagerImpl] ISPN000073: Unexpected error while replicating
> java.lang.NullPointerException
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendTo(JGroupsTransport.java:724)
> at org.infinispan.remoting.rpc.RpcManagerImpl.sendTo(RpcManagerImpl.java:254)
> at org.infinispan.interceptors.TriangleAckInterceptor.sendExceptionAck(TriangleAckInterceptor.java:266)
> at org.infinispan.interceptors.TriangleAckInterceptor.onRemotePrimaryOwner(TriangleAckInterceptor.java:158)
> at org.infinispan.interceptors.InvocationFinallyAction.apply(InvocationFinallyAction.java:18)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
> at org.infinispan.interceptors.InvocationStage.andFinally(InvocationStage.java:39)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:160)
> at org.infinispan.interceptors.TriangleAckInterceptor.handleWriteCommand(TriangleAckInterceptor.java:147)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months