[JBoss JIRA] (HRJS-33) Cluster tests randomly fail iteration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-33?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño updated HRJS-33:
---------------------------------
Fix Version/s: 0.4.0
(was: HRJS-18)
> Cluster tests randomly fail iteration
> -------------------------------------
>
> Key: HRJS-33
> URL: https://issues.jboss.org/browse/HRJS-33
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.3.0
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.4.0
>
> Attachments: server-trace-logs.tgz
>
>
> Very sheldon the cluster spec iteration tests fail with:
> {code}
> Failures:
> 1) Infinispan cluster client can iterate over entries in a cluster
> Message:
> java.util.NoSuchElementException
> Stacktrace:
> undefined
> 2) Infinispan cluster client can remove listener in cluster
> Message:
> timeout: timed out after 5000 msec waiting for spec to complete
> Stacktrace:
> undefined
> 3) Infinispan cluster client can execute a script remotely to store and retrieve data in cluster mode
> Message:
> Expected 'cluster-typed-key' to be 'listen-distinct-1'.
> Stacktrace:
> Error: Expected 'cluster-typed-key' to be 'listen-distinct-1'.
> at EventEmitter.<anonymous> (/Users/g/0/infinispan/js-client/spec/utils/testing.js:317:26)
> at EventEmitter.emit (events.js:106:17)
> at emitKeyVersion (/Users/g/0/infinispan/js-client/lib/protocols.js:411:29)
> at /Users/g/0/infinispan/js-client/lib/protocols.js:399:18
> at Function.<anonymous> (/Users/g/0/infinispan/js-client/lib/functional.js:185:16)
> at /Users/g/0/infinispan/js-client/lib/functional.js:173:19
> at ListenersMixin.decodeEvent (/Users/g/0/infinispan/js-client/lib/protocols.js:475:18)
> at Socket.onData (/Users/g/0/infinispan/js-client/lib/io.js:103:38)
> 4) Infinispan cluster client can execute a script remotely to store and retrieve data in cluster mode
> Message:
> timeout: timed out after 5000 msec waiting for spec to complete
> Stacktrace:
> undefined
> 5) Infinispan cluster client can execute a script remotely to store and retrieve data in distributed mode
> Message:
> Expected 'dist-cluster-typed-key' to be 'listen-distinct-1'.
> Stacktrace:
> Error: Expected 'dist-cluster-typed-key' to be 'listen-distinct-1'.
> at EventEmitter.<anonymous> (/Users/g/0/infinispan/js-client/spec/utils/testing.js:317:26)
> at EventEmitter.emit (events.js:106:17)
> at emitKeyVersion (/Users/g/0/infinispan/js-client/lib/protocols.js:411:29)
> at /Users/g/0/infinispan/js-client/lib/protocols.js:399:18
> at Function.<anonymous> (/Users/g/0/infinispan/js-client/lib/functional.js:185:16)
> at /Users/g/0/infinispan/js-client/lib/functional.js:173:19
> at ListenersMixin.decodeEvent (/Users/g/0/infinispan/js-client/lib/protocols.js:475:18)
> at Socket.onData (/Users/g/0/infinispan/js-client/lib/io.js:103:38)
> Finished in 12.721 seconds
> 10 tests, 26 assertions, 5 failures, 0 skipped
> {code}
> See attached TRACE logs from server (unfortunately no client logs)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7572?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7572:
------------------------------------
Fix Version/s: 8.2.7.Final
> 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: Sanne Grinovero
> 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)
9 years
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3918:
-----------------------------------
This situation can happen with triangle algorithm even without any topology change; as primary does not hold the lock during replication, second putIfAbsent may fail before the first putIfAbsent is executed on backup.
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: consistency
> Fix For: 9.0.0.Final
>
> Attachments: ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7519) NPE and Deadlock during server start
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7519?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7519:
------------------------------------
Fix Version/s: (was: 8.2.7.Final)
> NPE and Deadlock during server start
> ------------------------------------
>
> Key: ISPN-7519
> URL: https://issues.jboss.org/browse/ISPN-7519
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 9.0.0.CR1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.CR2
>
> Attachments: server-trace.txt, surefire-trace.txt
>
>
> When running the full test suite, it deadlocked when running the test {{StateTransferSuppressIT.testRebalanceWithFirstNodeStop}}.
> The server startup printed
> {noformat}
> 12:13:07,787 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Ruppaner' 9.0.0-SNAPSHOT
> 12:13:08,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) DGISPN0001: Started memcachedCache cache from clustered container
> 12:13:08,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) DGISPN0001: Started default cache from clustered container
> 12:13:08,181 INFO [org.infinispan.server.endpoint] (MSC service thread 1-4) DGENDPT10000: MemcachedServer starting
> 12:13:08,181 INFO [org.infinispan.server.endpoint] (MSC service thread 1-3) DGENDPT10000: HotRodServer starting
> 12:13:08,182 INFO [org.infinispan.server.endpoint] (MSC service thread 1-4) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211
> 12:13:08,182 INFO [org.infinispan.server.endpoint] (MSC service thread 1-3) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222
> 12:13:08,188 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10000: REST starting
> 12:13:08,259 WARNING [io.netty.channel.epoll.EpollEventLoop] (MemcachedServerMaster-1-1) Unexpected exception in the selector loop.: java.lang.NullPointerException
> at io.netty.util.internal.shaded.org.jctools.queues.MpscChunkedArrayQueue.poll(MpscChunkedArrayQueue.java:264)
> at io.netty.util.concurrent.SingleThreadEventExecutor.pollTaskFrom(SingleThreadEventExecutor.java:223)
> at io.netty.util.concurrent.SingleThreadEventExecutor.pollTask(SingleThreadEventExecutor.java:218)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:408)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:306)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:873)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> 12:13:08,338 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-1) ISPN012003: REST server starting, listening on 127.0.0.1:8080
> 12:13:08,338 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10002: REST mapped to /rest
> {noformat}
> and then hanged. Attached is the stack trace of the server, and the forked test process.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years