[JBoss JIRA] (ISPN-4125) ClassCastException if cache.keyset() is invoked for a string-keyed-jdbc-store in C/S mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4125?page=com.atlassian.jira.plugin.... ]
Adrian Nistor edited comment on ISPN-4125 at 3/26/14 8:10 AM:
--------------------------------------------------------------
It finally turns out I can reproduce this only on mysql. Strangely, it works fine with H2, which is used in the test suite.
The root cause is DefaultTwoWayKey2StringMapper using an unsafe way of encoding a byte[] into a String. It uses a special unicode character (0xFEFF) as prefix for all strings which were mapped and need unmapping when fetched later. Unicode character 0xFEFF is a silent character used for detecting the byte order of the string. Using it for our purpose seems like a neat trick. Unfortunately when the database actually sees this string it is free to interpret the byte ordering instruction and convert the string to native byte order and then discard the marker as no longer necessary. This leaves us with no clue the string was 'marked' by us. Mysql is such a database, while H2 seems to not interfere here.
After isolating this problem to DefaultTwoWayKey2StringMapper I propose to close this issue and open a new one.
was (Author: anistor):
It finally turns out I can reproduce this only on mysql. Strangely, it works fine with H2, which is used in the test suite.
> ClassCastException if cache.keyset() is invoked for a string-keyed-jdbc-store in C/S mode
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4125
> URL: https://issues.jboss.org/browse/ISPN-4125
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 6.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Adrian Nistor
> Labels: 621, 630
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
> Attachments: reproducer.zip
>
>
> If the cache is empty cache.keyset() invocation returns an empty set.
> If it is invoked after entities are added it failes with the Exception below.
> The same test work if a binary-keyed-jdbc-store is used!
> The HotRod client is based on the hot-rod C/S quickstart.
> The configuration is:
> <subsystem xmlns="urn:infinispan:server:core:6.0" default-cache-container="clustered">
> <cache-container name="clustered" default-cache="string" statistics="true">
> <transport executor="infinispan-transport" lock-timeout="60000"/>
> <replicated-cache name="string" mode="ASYNC" start="EAGER">
> <locking isolation="READ_COMMITTED" acquire-timeout="20000" concurrency-level="500" striping="false"/>
> <transaction mode="NONE"/>
> <string-keyed-jdbc-store datasource="java:jboss/datasources/JDGDatasource" passivation="false" preload="true" purge="false" shared="false">
> <!-- property name="databaseType">ORACLE</property -->
> <string-keyed-table prefix="qs">
> <id-column name="id" type="VARCHAR(255)"/>
> <data-column name="datum" type="BLOB(2000)"/>
> <timestamp-column name="version" type="BIGINT"/>
> </string-keyed-table>
> <write-behind modification-queue-size="1024" shutdown-timeout="25000" flush-lock-timeout="15000" thread-pool-size="5" />
> </string-keyed-jdbc-store>
> <expiration interval="10000" />
> </replicated-cache>
> ERROR [org.infinispan.server.hotrod.HotRodDecoder:76] (HotRodServerWorker-88) ISPN005009: Unexpected error before any request parameters read: java.lang.ClassCastException: java.lang.String cannot be cast to [B
> at org.infinispan.server.hotrod.AbstractEncoder1x$$anonfun$writeResponse$5.apply(AbstractEncoder1x.scala:113) [infinispan.jar:7.0.0-SNAPSHOT]
> at scala.collection.Iterator$class.foreach(Iterator.scala:727)
> at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
> at org.infinispan.server.hotrod.AbstractEncoder1x.writeResponse(AbstractEncoder1x.scala:113) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:48) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:704) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:671) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) [netty-3.6.6.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:163) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:138) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:105) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:53) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:29) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) [netty-3.6.6.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:377) [infinispan.jar:7.0.0-SNAPSHOT]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.6.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.6.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-4137:
-----------------------------------
{quote}
The CommitCommand won't be lost, but that's not the problem. The problem is that once the originator times out waiting for a backup's response, it will send a RollbackCommand which will release the lock on the primary owner, so it's no longer ok to run the CommitCommand on the backup. If we retried the CommitCommand, that would mean the locks on the primary would still be valid at the time (one of) the CommitCommands is executed on the backup. Mircea suggested another solution here: change RollbackCommand to no longer release the locks, and to require a separate TxCompletionNotificationCommand. That way, the backup will either commit while holding the lock, or roll back.
{quote}
I agree that the Rollback should not be sent after timeout in commit. But I don't understand what would we gain if the lock release was in TxCompletion - the Rollback might then release the few resources. For further writes, the lock is held all the time - no difference - and reads without force write lock can return current or future value anyway (even in correct situations the transaction commit is not atomic with respect to reads). It could be even worse - if you allowed to rollback after commit, you could read uncommitted value for a while.
Maybe an example sequence commands would help me understanding.
{quote}
Trying to commit the tx without holding the proper locks isn't good either, as you risk breaking other transactions as well. We could try to eliminate the replication timeout for commit commands completely, but that would still leave a stale lock if there is a bug somewhere in the commit code. I think it would be better to allow a bigger timeout for commit commands, but keep a timeout nonetheless.
{quote}
I am not suggesting that - if Prepare was successful, once we sent the Commit, we have to kick all owners to commit the transaction, eventually. Only in the case that all nodes are found prepared and originator is dead, we may rollback the commit.
If primary keeps alive, it should synchronize further transactions by holding the lock (and releasing with commit) - backups don't matter, they will either commit the new value as well (the lock is held on primary), or the one change won't be spotted. If the primary dies, new primary should acquire the lock and not release it until it receives the commit command, synchronizing the writes again.
There should be no reason for a prepared transaction to fail. Network failures should be fixed by JGroups, eventually. Timeouts should release application threads, potentially some worker threads to do another work, but these should not change the logical output of the operation.
Bugs in code may happen, but user should find out that there's something wrong (locking repeatedly fails due to stale lock) - that's where the human intervention through recovery could be useful. For handling bugs in production.
{quote}
If recovery is not enabled, the tx is just rolled back.
{quote}
So this is not correct either - some nodes may have already committed it. We can't rollback unless we're sure that nobody committed, that should be a firm rule when designing the system.
> Transaction executed multiple times due to forwarded CommitCommand
> ------------------------------------------------------------------
>
> Key: ISPN-4137
> URL: https://issues.jboss.org/browse/ISPN-4137
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer, Transactions
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well.
> Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}.
> However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4137:
------------------------------------
{quote}
I don't see the point in committing indefinitely. There's now way how the CommitCommand can be lost - JGroups should deliver it reliably, and we are not dropping delivered commands anywhere in Infinispan (or do we?). It can just take a while before it is delivered and responded. The only consideration for any resending is sending to new nodes.
{quote}
The CommitCommand won't be lost, but that's not the problem. The problem is that once the originator times out waiting for a backup's response, it will send a RollbackCommand which will release the lock on the primary owner, so it's no longer ok to run the CommitCommand on the backup. If we retried the CommitCommand, that would mean the locks on the primary would still be valid at the time (one of) the CommitCommands is executed on the backup. Mircea suggested another solution here: change RollbackCommand to no longer release the locks, and to require a separate TxCompletionNotificationCommand. That way, the backup will either commit while holding the lock, or roll back.
{quote}
What's the contract, anyway? When the commit() throws exception, are there any guarantees that none of the operations were written? Is this described anywhere?
{quote}
I'm not sure if it's written anywhere, but if we throw an exception during commit then there are no guarantees as to what is written on which nodes. However, I think you were right to create this issue, as overwriting another transaction's data shouldn't be allowed.
{quote}
If there are no such guarantees, trying to finish the TX with commit even if exception was reported on originator is IMO better than send a rollback (and hope things will settle) or keeping the locks stale. If there are any such guarantees, we can't do anything, and we should rather keep the lock stale (blocking further txs) than break the contract. Thinking about it again, there can't be any guarantees because the commit can be already executed - the contract would be broken.
{quote}
Trying to commit the tx without holding the proper locks isn't good either, as you risk breaking other transactions as well. We could try to eliminate the replication timeout for commit commands completely, but that would still leave a stale lock if there is a bug somewhere in the commit code. I think it would be better to allow a bigger timeout for commit commands, but keep a timeout nonetheless.
{quote}
When the originator dies after prepare, the transaction keeps hanging anyway. Is it then reported in-doubt in recovery?
{quote}
Yes, {{RecoveryAwareTransactionTable.cleanupStaleTransactions()}} moves the tx from the tx table to the recovery cache. If recovery is not enabled, the tx is just rolled back.
Either way, there is no coordination between the owners at this point, so if there is a failure during commit, some of the owners may commit (without holding the key locks) and some may roll back. There is already a bug for this, but I can't find it at the moment.
> Transaction executed multiple times due to forwarded CommitCommand
> ------------------------------------------------------------------
>
> Key: ISPN-4137
> URL: https://issues.jboss.org/browse/ISPN-4137
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer, Transactions
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well.
> Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}.
> However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-3796) ClusteredQueryDslConditionsTest fails randomly
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3796?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3796:
------------------------------------
Description:
See stacktrace:
{noformat}
testSampleDomainQuery16(org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest) Time elapsed: 0.143 sec <<< FAILURE!
org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredQueryDslConditionsTest-NodeDE-6251, see cause for remote stack trace
at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
at org.infinispan.query.indexmanager.InfinispanCommandsBackend.sendCommand(InfinispanCommandsBackend.java:87)
at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyWork(InfinispanCommandsBackend.java:81)
at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:53)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
at org.hibernate.search.backend.impl.WorkQueuePerIndexSplitter.commitOperations(WorkQueuePerIndexSplitter.java:63)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:99)
at org.hibernate.search.backend.impl.TransactionalWorker.performWork(TransactionalWorker.java:105)
at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:233)
at org.infinispan.query.backend.QueryInterceptor.performSearchWork(QueryInterceptor.java:227)
at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:221)
at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:164)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:45)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:214)
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:327)
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1296)
at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
at org.infinispan.CacheImpl.put(CacheImpl.java:861)
at org.infinispan.CacheImpl.put(CacheImpl.java:1349)
at org.infinispan.CacheImpl.put(CacheImpl.java:206)
at org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16(ClusteredQueryDslConditionsTest.java:1059)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
Caused by: org.hibernate.search.SearchException: Error applying updates to the Lucene index
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.applyWork(LuceneBackendQueueProcessor.java:106)
at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:49)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
at org.infinispan.query.indexmanager.IndexUpdateCommand.perform(IndexUpdateCommand.java:53)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
... 3 more
Caused by: java.lang.AssertionError: file _b.fdt does not exist
at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4492)
at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4543)
at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3414)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
... 3 more
Results :
Failed tests:
ClusteredQueryDslConditionsTest.testSampleDomainQuery16:1059 » Remote ISPN0002...
Tests run: 1036, Failures: 1, Errors: 0, Skipped: 0
{noformat}
Test fails very often on RHEL
org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16
here is trace log https://www.dropbox.com/s/yvrbs2i2tvh0wzz/ClusteredQueryDslConditionsTest...
was:
See stacktrace:
{noformat}
testSampleDomainQuery16(org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest) Time elapsed: 0.143 sec <<< FAILURE!
org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredQueryDslConditionsTest-NodeDE-6251, see cause for remote stack trace
at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
at org.infinispan.query.indexmanager.InfinispanCommandsBackend.sendCommand(InfinispanCommandsBackend.java:87)
at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyWork(InfinispanCommandsBackend.java:81)
at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:53)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
at org.hibernate.search.backend.impl.WorkQueuePerIndexSplitter.commitOperations(WorkQueuePerIndexSplitter.java:63)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:99)
at org.hibernate.search.backend.impl.TransactionalWorker.performWork(TransactionalWorker.java:105)
at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:233)
at org.infinispan.query.backend.QueryInterceptor.performSearchWork(QueryInterceptor.java:227)
at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:221)
at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:164)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:45)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:214)
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:327)
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1296)
at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
at org.infinispan.CacheImpl.put(CacheImpl.java:861)
at org.infinispan.CacheImpl.put(CacheImpl.java:1349)
at org.infinispan.CacheImpl.put(CacheImpl.java:206)
at org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16(ClusteredQueryDslConditionsTest.java:1059)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
Caused by: org.hibernate.search.SearchException: Error applying updates to the Lucene index
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.applyWork(LuceneBackendQueueProcessor.java:106)
at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:49)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
at org.infinispan.query.indexmanager.IndexUpdateCommand.perform(IndexUpdateCommand.java:53)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
... 3 more
Caused by: java.lang.AssertionError: file _b.fdt does not exist
at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4492)
at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4543)
at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3414)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
... 3 more
Results :
Failed tests:
ClusteredQueryDslConditionsTest.testSampleDomainQuery16:1059 » Remote ISPN0002...
Tests run: 1036, Failures: 1, Errors: 0, Skipped: 0
{noformat}
> ClusteredQueryDslConditionsTest fails randomly
> ----------------------------------------------
>
> Key: ISPN-3796
> URL: https://issues.jboss.org/browse/ISPN-3796
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Test Suite - Core
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
>
> See stacktrace:
> {noformat}
> testSampleDomainQuery16(org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest) Time elapsed: 0.143 sec <<< FAILURE!
> org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredQueryDslConditionsTest-NodeDE-6251, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.sendCommand(InfinispanCommandsBackend.java:87)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyWork(InfinispanCommandsBackend.java:81)
> at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:53)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
> at org.hibernate.search.backend.impl.WorkQueuePerIndexSplitter.commitOperations(WorkQueuePerIndexSplitter.java:63)
> at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:99)
> at org.hibernate.search.backend.impl.TransactionalWorker.performWork(TransactionalWorker.java:105)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:233)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWork(QueryInterceptor.java:227)
> at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:221)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:45)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:214)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:327)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1296)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
> at org.infinispan.CacheImpl.put(CacheImpl.java:861)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1349)
> at org.infinispan.CacheImpl.put(CacheImpl.java:206)
> at org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16(ClusteredQueryDslConditionsTest.java:1059)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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)
> Caused by: org.hibernate.search.SearchException: Error applying updates to the Lucene index
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.applyWork(LuceneBackendQueueProcessor.java:106)
> at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:49)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
> at org.infinispan.query.indexmanager.IndexUpdateCommand.perform(IndexUpdateCommand.java:53)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
> ... 3 more
> Caused by: java.lang.AssertionError: file _b.fdt does not exist
> at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4492)
> at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4543)
> at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3414)
> at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
> at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ... 3 more
> Results :
> Failed tests:
> ClusteredQueryDslConditionsTest.testSampleDomainQuery16:1059 » Remote ISPN0002...
> Tests run: 1036, Failures: 1, Errors: 0, Skipped: 0
> {noformat}
> Test fails very often on RHEL
> org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16
> here is trace log https://www.dropbox.com/s/yvrbs2i2tvh0wzz/ClusteredQueryDslConditionsTest...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-4029) NotifyingFutureTest.testExceptionOtherThread1 && testDoneOtherThread2 random failures
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4029?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4029:
------------------------------------
Description:
{noformat}
16:58:33,402 ERROR (testng-NotifyingFutureTest:) [UnitTestTestNGListener] Test testExceptionOtherThread1(org.infinispan.commons.util.concurrent.NotifyingFutureTest) failed.
java.lang.AssertionError: expected [true] but found [false]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertTrue(Assert.java:42)
at org.testng.Assert.assertTrue(Assert.java:52)
at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testException(NotifyingFutureTest.java:150)
at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread(NotifyingFutureTest.java:67)
at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread1(NotifyingFutureTest.java:46)
{noformat}
The test submits a task to a ThreadPoolExecutor that notifies a NotifyingFutureImpl and assumes that when the NotifyingFutureImpl is done, the original Future is also done. That's clearly not happening some of the time.
* Jenkins
** RHEL, Oracle JDK7
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
** RHEL, OpenJDK7
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
was:
{noformat}
16:58:33,402 ERROR (testng-NotifyingFutureTest:) [UnitTestTestNGListener] Test testExceptionOtherThread1(org.infinispan.commons.util.concurrent.NotifyingFutureTest) failed.
java.lang.AssertionError: expected [true] but found [false]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertTrue(Assert.java:42)
at org.testng.Assert.assertTrue(Assert.java:52)
at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testException(NotifyingFutureTest.java:150)
at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread(NotifyingFutureTest.java:67)
at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread1(NotifyingFutureTest.java:46)
{noformat}
The test submits a task to a ThreadPoolExecutor that notifies a NotifyingFutureImpl and assumes that when the NotifyingFutureImpl is done, the original Future is also done. That's clearly not happening some of the time.
> NotifyingFutureTest.testExceptionOtherThread1 && testDoneOtherThread2 random failures
> -------------------------------------------------------------------------------------
>
> Key: ISPN-4029
> URL: https://issues.jboss.org/browse/ISPN-4029
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
>
> {noformat}
> 16:58:33,402 ERROR (testng-NotifyingFutureTest:) [UnitTestTestNGListener] Test testExceptionOtherThread1(org.infinispan.commons.util.concurrent.NotifyingFutureTest) failed.
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testException(NotifyingFutureTest.java:150)
> at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread(NotifyingFutureTest.java:67)
> at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread1(NotifyingFutureTest.java:46)
> {noformat}
> The test submits a task to a ThreadPoolExecutor that notifies a NotifyingFutureImpl and assumes that when the NotifyingFutureImpl is done, the original Future is also done. That's clearly not happening some of the time.
> * Jenkins
> ** RHEL, Oracle JDK7
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> ** RHEL, OpenJDK7
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-4029) NotifyingFutureTest.testExceptionOtherThread1 && testDoneOtherThread2 random failures
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4029?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4029:
------------------------------------
Summary: NotifyingFutureTest.testExceptionOtherThread1 && testDoneOtherThread2 random failures (was: NotifyingFutureTest.testExceptionOtherThread1 random failures)
> NotifyingFutureTest.testExceptionOtherThread1 && testDoneOtherThread2 random failures
> -------------------------------------------------------------------------------------
>
> Key: ISPN-4029
> URL: https://issues.jboss.org/browse/ISPN-4029
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
>
> {noformat}
> 16:58:33,402 ERROR (testng-NotifyingFutureTest:) [UnitTestTestNGListener] Test testExceptionOtherThread1(org.infinispan.commons.util.concurrent.NotifyingFutureTest) failed.
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testException(NotifyingFutureTest.java:150)
> at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread(NotifyingFutureTest.java:67)
> at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread1(NotifyingFutureTest.java:46)
> {noformat}
> The test submits a task to a ThreadPoolExecutor that notifies a NotifyingFutureImpl and assumes that when the NotifyingFutureImpl is done, the original Future is also done. That's clearly not happening some of the time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-3650) Test of org.infinispan.persistence.rest fail randomly on all environments
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3650?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3650:
------------------------------------
Description:
The tests of the package org.infinispan.persistence.rest fail periodically on Windows and Solaris and RHEL machines.
* Tests wich fail most likely
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testCancelingTaskMultipleProcessors
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testSequentialIteration
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testParallelIteration
>>> org.infinispan.persistence.rest.RestCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.clearContent
You can find the log attached.
* Jenkins job for RHEL could be found here
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
* Jenkins job for Windows
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
was:
The tests of the package org.infinispan.persistence.rest fail periodically on Windows and Solaris and RHEL machines.
* Tests wich fail most likely
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testCancelingTaskMultipleProcessors
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testSequentialIteration
>>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testParallelIteration
>>> org.infinispan.persistence.rest.RestCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap
You can find the log attached.
* Jenkins job for RHEL could be found here
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
* Jenkins job for Windows
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> Test of org.infinispan.persistence.rest fail randomly on all environments
> -------------------------------------------------------------------------
>
> Key: ISPN-3650
> URL: https://issues.jboss.org/browse/ISPN-3650
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Test Suite - Core
> Affects Versions: 6.0.0.CR1, 6.0.0.Final
> Environment: Windows && Solaris && RHEL
> Reporter: Anna Manukyan
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Attachments: rest-trace-infinispan.log.zip, traces_rhel.zip
>
>
> The tests of the package org.infinispan.persistence.rest fail periodically on Windows and Solaris and RHEL machines.
> * Tests wich fail most likely
> >>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testCancelingTaskMultipleProcessors
> >>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testSequentialIteration
> >>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.testParallelIteration
> >>> org.infinispan.persistence.rest.RestCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap
> >>> org.infinispan.persistence.rest.RestStoreParallelIterationTest.clearContent
> You can find the log attached.
> * Jenkins job for RHEL could be found here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> * Jenkins job for Windows
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years