[JBoss JIRA] (ISPN-4560) FD_SOCK client socket connection timeout in the test suite
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4560:
----------------------------------
Summary: FD_SOCK client socket connection timeout in the test suite
Key: ISPN-4560
URL: https://issues.jboss.org/browse/ISPN-4560
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core, Test Suite - Core
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Beta1
At least some of the {{createBeforeMethod}} failures in the test suite seem to be caused by FD_SOCK, which is not able to connect to its peer:
{noformat}
08:28:08,144 DEBUG (testng-L1StateTransferOverwriteTest:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827]
08:28:12,558 DEBUG (Incoming-1,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942]
08:28:12,631 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: ping_dest is L1StateTransferOverwriteTest-NodeBD-12942, pingable_mbrs=[L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942]
08:28:12,716 DEBUG (testng-L1StateTransferOverwriteTest:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBD-12942: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942]
08:28:12,719 DEBUG (ViewHandler,NodeBC-2827:) [STABLE] resuming message garbage collection
08:28:20,213 WARN (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: creating the client socket failed: java.net.SocketTimeoutException
08:28:20,230 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: could not create socket to L1StateTransferOverwriteTest-NodeBD-12942 (pinger thread is running)
08:28:20,230 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: suspecting L1StateTransferOverwriteTest-NodeBD-12942
08:28:20,230 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: ping_dest is null, pingable_mbrs=[L1StateTransferOverwriteTest-NodeBC-2827]
08:28:20,232 DEBUG (INT-1,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: suspecting [L1StateTransferOverwriteTest-NodeBD-12942]
08:28:20,241 DEBUG (Incoming-1,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827]
08:28:21,442 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBD-12942:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBD-12942: ping_dest is L1StateTransferOverwriteTest-NodeBC-2827, pingable_mbrs=[L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942]
08:28:21,442 DEBUG (FD_SOCK pinger,NodeBD-12942:) [FD_SOCK] NodeBD-12942: ping_dest is NodeBC-2827, pingable_mbrs=[NodeBC-2827, NodeBD-12942]
{noformat}
There is no message in the log for about 8 seconds (at least for this test), so the timeout could be caused by a GC and/or StateTransferFunctionalTest using too much CPU.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4559) Replace fails with cache loader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4559?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4559:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1122269
> Replace fails with cache loader
> -------------------------------
>
> Key: ISPN-4559
> URL: https://issues.jboss.org/browse/ISPN-4559
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dennis Reed
> Assignee: Dan Berindei
>
> cache.replace(key, oldValue, newValue) compares the current value in the cache to oldValue, and if they differ it turns into a no-op.
> However, CacheLoaderInterceptor does not load entries for a ReplaceCommand.
> If the entry only exists in the loader and not in memory, this causes the replace to fail.
> CacheLoaderInterceptor must always load the value for a ReplaceCommand.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4517) RollbackCommands should ignore leavers
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4517?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4517:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> RollbackCommands should ignore leavers
> --------------------------------------
>
> Key: ISPN-4517
> URL: https://issues.jboss.org/browse/ISPN-4517
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
>
> When one of the targets of a PrepareCommand leaves, the originator receives a SuspectException and tries to roll back the transaction. However, the RollbackCommand can also fail with with a SuspectException if:
> * syncRollbackPhase = true (the default, since ISPN-4137)
> * The cache topology hasn't been updated to exclude the leaver yet (maybe because it was the old coordinator that left)
> In that case, we could throw a SuspectException in JGroupsTransport.invokeRemotely without sending the RollbackCommand to the other owner:
> {noformat}
> 23:34:01,219 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (PrivateLogChecker-4) ISPN000136: Execution error
> org.infinispan.remoting.transport.jgroups.SuspectException: One or more nodes have left the cluster while replicating command RollbackCommand {gtx=GlobalTransaction:<edg-perf08-52473>:1077:local, cacheName='testCache', topologyId=8}
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:486)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRollbackCommand(TxDistributionInterceptor.java:223)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> 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.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitRollbackCommand(AbstractTxLockingInterceptor.java:51)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.NotificationInterceptor.visitRollbackCommand(NotificationInterceptor.java:50)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.visitRollbackCommand(TxInterceptor.java:207)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> 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.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitRollbackCommand(TransactionSynchronizerInterceptor.java:66)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:222)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:153)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitRollbackCommand(StateTransferInterceptor.java:91)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> 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.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.transaction.TransactionCoordinator.rollbackInternal(TransactionCoordinator.java:237)
> at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:172)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1436)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:904)
> at org.infinispan.CacheImpl.put(CacheImpl.java:896)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1471)
> at org.infinispan.CacheImpl.put(CacheImpl.java:231)
> at org.radargun.cachewrappers.InfinispanBasicOperations.put(InfinispanBasicOperations.java:25)
> at org.radargun.cachewrappers.Infinispan51BasicOperations.put(Infinispan51BasicOperations.java:31)
> at org.radargun.cachewrappers.Infinispan52BasicOperations.put(Infinispan52BasicOperations.java:16)
> at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:185)
> at org.radargun.stressors.LogChecker.run(LogChecker.java:106)
> {noformat}
> The RollbackCommand should have the SYNCHRONOUS_IGNORE_LEAVERS ResponseMode, so that the owner still alive receives the the command. Otherwise, that stale transaction will never be completed.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4559) Replace fails with cache loader
by Dennis Reed (JIRA)
Dennis Reed created ISPN-4559:
---------------------------------
Summary: Replace fails with cache loader
Key: ISPN-4559
URL: https://issues.jboss.org/browse/ISPN-4559
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Loaders and Stores
Affects Versions: 7.0.0.Alpha5
Reporter: Dennis Reed
Assignee: Dan Berindei
cache.replace(key, oldValue, newValue) compares the current value in the cache to oldValue, and if they differ it turns into a no-op.
However, CacheLoaderInterceptor does not load entries for a ReplaceCommand.
If the entry only exists in the loader and not in memory, this causes the replace to fail.
CacheLoaderInterceptor must always load the value for a ReplaceCommand.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4519) Prepare should be broadcasted to entire cluster in replicated mode
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4519?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4519:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Prepare should be broadcasted to entire cluster in replicated mode
> ------------------------------------------------------------------
>
> Key: ISPN-4519
> URL: https://issues.jboss.org/browse/ISPN-4519
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> TxDistributionInterceptor.visitPrepareCommand explicitly checks if the {{recipients}} collection is {{null}} and replaces it with the list of cache members. This was done for total order, but TOA now supports sending messages to {{null}}, so there is no reason to handle this in our code.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4323) ConditionalOperationsConcurrentWriteSkewTest fails randomly on RHEL
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4323?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4323:
------------------------------------
Lots of failure in CI with TRACE logs: http://ci.infinispan.org/project.html?tab=testDetails&testNameId=-2370759...
> ConditionalOperationsConcurrentWriteSkewTest fails randomly on RHEL
> -------------------------------------------------------------------
>
> Key: ISPN-4323
> URL: https://issues.jboss.org/browse/ISPN-4323
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha1, 7.0.0.Alpha2, 7.0.0.Alpha3, 7.0.0.Alpha4
> Environment: RHEL and Open JDK
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Attachments: ConditionalOperationsConcurrentWriteSkewTest.log.zip, ConditionalOperationsConcurrentWriteSkewTest.tar.bz2
>
>
> Following tests fail with TImeout exception
> org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testConditionalRemove
> org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testReplace
> org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testPutIfAbsent
> {noformat}
> java.lang.AssertionError: java.lang.RuntimeException: java.util.concurrent.TimeoutException
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.infinispan.api.ConditionalOperationsConcurrentTest.testOnCaches(ConditionalOperationsConcurrentTest.java:129)
> at org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testConditionalRemove(ConditionalOperationsConcurrentWriteSkewTest.java:56)
> 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:744)
> {noformat}
> Failing tests in Jenkins
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4323) ConditionalOperationsConcurrentWriteSkewTest fails randomly on RHEL
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4323?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4323:
-------------------------------
Priority: Blocker (was: Major)
> ConditionalOperationsConcurrentWriteSkewTest fails randomly on RHEL
> -------------------------------------------------------------------
>
> Key: ISPN-4323
> URL: https://issues.jboss.org/browse/ISPN-4323
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha1, 7.0.0.Alpha2, 7.0.0.Alpha3, 7.0.0.Alpha4
> Environment: RHEL and Open JDK
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Attachments: ConditionalOperationsConcurrentWriteSkewTest.log.zip, ConditionalOperationsConcurrentWriteSkewTest.tar.bz2
>
>
> Following tests fail with TImeout exception
> org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testConditionalRemove
> org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testReplace
> org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testPutIfAbsent
> {noformat}
> java.lang.AssertionError: java.lang.RuntimeException: java.util.concurrent.TimeoutException
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.infinispan.api.ConditionalOperationsConcurrentTest.testOnCaches(ConditionalOperationsConcurrentTest.java:129)
> at org.infinispan.api.ConditionalOperationsConcurrentWriteSkewTest.testConditionalRemove(ConditionalOperationsConcurrentWriteSkewTest.java:56)
> 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:744)
> {noformat}
> Failing tests in Jenkins
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4558) New ThreadPoolExecutorFactory API is awkward to implement
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-4558:
----------------------------------
Summary: New ThreadPoolExecutorFactory API is awkward to implement
Key: ISPN-4558
URL: https://issues.jboss.org/browse/ISPN-4558
Project: Infinispan
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 7.0.0.Alpha5
Reporter: Paul Ferraro
Assignee: Dan Berindei
7.0.0.Alpha5 introduced a new ThreadPoolExecutorFactory, but the API is awkward to implement. The createExecutor(ThreadFactory) method returns a generic type, but the type of the expected result is not known to the implementor! Consequently, the implementor needs to resort to type erasure in order to force the implementation to compile.
I suggest that this implement simply return ExecutorService, and allow ScheduledExecutorService variants to override the return value. If parameterization of the ExecutorService implementation is indeed necessary, the class itself should probably be parameterized instead, since a given implementation of ThreadPoolExecutorFactory would not likely return more than one type of ExecutorService implementation.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (ISPN-4557) Infinispan Core module for the application server not importing Services from the Query module
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-4557:
-------------------------------------
Summary: Infinispan Core module for the application server not importing Services from the Query module
Key: ISPN-4557
URL: https://issues.jboss.org/browse/ISPN-4557
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Embedded Querying
Affects Versions: 7.0.0.Alpha5
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 7.0.0.Beta1
The module definition of Infinispan Core (the JDG main module) depends on the Query module but fails to import the Services.
Not loading the services allows the Indexing feature to be enabled, although several operations will fail at runtime.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months