[JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxServiceCleanup thread pool even when the cache is NOT_TRANSACTIONAL
by Guillermo GARCIA OCHOA (JIRA)
Guillermo GARCIA OCHOA created ISPN-4027:
--------------------------------------------
Summary: TransactionTable.start() initialize the TxServiceCleanup thread pool even when the cache is NOT_TRANSACTIONAL
Key: ISPN-4027
URL: https://issues.jboss.org/browse/ISPN-4027
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.1.Final
Reporter: Guillermo GARCIA OCHOA
Assignee: Mircea Markus
In the {{TransactionTable.start()}} each cache creates a thread pool and a job is scheduled to clean up completed transactions.
{code:java}
private void start() {
...
totalOrder = configuration.transaction().transactionProtocol().isTotalOrder();
if (!totalOrder) {
// Periodically run a task to cleanup the transaction table from completed transactions.
ThreadFactory tf = new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
th.setDaemon(true);
return th;
}
};
executorService = Executors.newSingleThreadScheduledExecutor(tf);
long interval = configuration.transaction().reaperWakeUpInterval();
executorService.scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
cleanupCompletedTransactions();
}
}, interval, interval, TimeUnit.MILLISECONDS);
}
}
{code}
As you can see in the code, even is the cache is {{NON_TRANSACTIONAL}} the job is scheduled, consuming resources to do nothing (the {{completedTransactions}} map is always empty)
Maybe I'm missing something, but our application profiling is showing us that these threads do nothing but they are consuming precious resources because we have more than 1000 {{NON_TRANSACTIONAL}} caches.
--
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, 1 month
[JBoss JIRA] (ISPN-2910) Divide by zero exception on shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2910:
-----------------------------------------------
Richard Janík <rjanik(a)redhat.com> changed the Status of [bug 920079|https://bugzilla.redhat.com/show_bug.cgi?id=920079] from ON_QA to VERIFIED
> Divide by zero exception on shutdown
> ------------------------------------
>
> Key: ISPN-2910
> URL: https://issues.jboss.org/browse/ISPN-2910
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Labels: nbst
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> 19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web]
> 19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
--
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, 1 month
[JBoss JIRA] (ISPN-2589) NPE in InvalidateL1Command
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2589?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2589:
-----------------------------------------------
Richard Janík <rjanik(a)redhat.com> changed the Status of [bug 916988|https://bugzilla.redhat.com/show_bug.cgi?id=916988] from ON_QA to VERIFIED
> NPE in InvalidateL1Command
> --------------------------
>
> Key: ISPN-2589
> URL: https://issues.jboss.org/browse/ISPN-2589
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 5.2.0.Beta5, 5.2.7.Final
> Reporter: Thomas Fromm
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
> Attachments: standalone_node0001.xml
>
>
> The used cache is an REPL_SYNC one w/o L1 and Optimistic TX.
> Can't provide unit test, just saw it in my logs.
> WARN 05.12.12 20:08:22,746 [OOB-173,IBIS-2147] CacheTopologyControlCommand ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=MODULE_PROPERTIES_VERSION, type=CH_UPDATE, sender=IBIS-57850, joinInfo=null, topologyId=14, currentCH=ReplicatedConsistentHash{members=[IBIS-57850, IBIS-15651, IBIS-14611, IBIS-7942, IBIS-4256, IBIS-25472, IBIS-32523]}, pendingCH=null, throwable=null, viewId=8}
> java.lang.NullPointerException
> at org.infinispan.commands.write.InvalidateL1Command.perform(InvalidateL1Command.java:109)
> at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:110)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitInvalidateCommand(CacheLoaderInterceptor.java:127)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitInvalidateL1Command(EntryWrappingInterceptor.java:143)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateL1Command(AbstractLockingInterceptor.java:99)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:256)
> at org.infinispan.interceptors.TxInterceptor.visitInvalidateCommand(TxInterceptor.java:224)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitInvalidateL1Command(StateTransferInterceptor.java:172)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:592)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:239)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:58)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:117)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FC.up(FC.java:479)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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, 1 month
[JBoss JIRA] (ISPN-2203) Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2203?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2203:
------------------------------------
Apparently, if the machine is loaded enough, the delay between successive {{cache.containsKey(k)}} checks can be > 1s, even though the test does a {{Thread.sleep(50)}}:
{noformat}
03:20:54.023 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (testng-AsyncAPITest) Invoked with command GetKeyValueCommand {key=k, flags=null} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@3406e2c6]
03:20:54.026 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (testng-AsyncAPITest) Found value v5
03:20:55.047 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (testng-AsyncAPITest) Invoked with command GetKeyValueCommand {key=k, flags=null} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@3bb50d05]
{noformat}
We should probably increase the {{maxIdle}} value from 1s to 2s. Interesting enough, I got the failure without having trace logging enabled.
> Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable
> -------------------------------------------------------------------
>
> Key: ISPN-2203
> URL: https://issues.jboss.org/browse/ISPN-2203
> Project: Infinispan
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 5.2.0.Beta2, 5.3.0.Beta2, 6.0.0.Alpha2
>
> Attachments: AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle.tar.gz, testAsyncMethodWithLifespanAndMaxIdle-0.log
>
>
> Test being disabled as part of ISPN-2196 cos it's unstable.
--
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, 1 month
[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 2.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3533?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3533:
----------------------------------------
More ideas:
* Hot Rod client is having to parse error message from server to detect suspects. It actually checks for `SuspectException` or `SuspectedException` in the error message. This is hacky. We should add a new error code for node suspicion, so that the client can react accordingly. There's planned work to silence them (ISPN-2577), but in case they ever bubble to clients, they should be handled properly.
> Design HotRod protocol version 2.0
> ----------------------------------
>
> Key: ISPN-3533
> URL: https://issues.jboss.org/browse/ISPN-3533
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> Umbrella JIRA for Hot Rod improvements for version 2.0
--
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, 1 month
[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 2.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3533?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño edited comment on ISPN-3533 at 2/19/14 10:14 AM:
------------------------------------------------------------------
Some ideas:
* Remove Transaction Type and Transaction Id from header. Even when transactions are implemented, not all operations will be transaction, e.g. ping, stats...etc, so we should not force these fields on all operations.
was (Author: galder.zamarreno):
Some ideas:
* Remove Transaction Type and Transaction Id from header. Even when transactions are implemented, not all operations will be transaction, i.e. ping, stats...etc, so we should not force these fields on all operations.
> Design HotRod protocol version 2.0
> ----------------------------------
>
> Key: ISPN-3533
> URL: https://issues.jboss.org/browse/ISPN-3533
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> Umbrella JIRA for Hot Rod improvements for version 2.0
--
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, 1 month
[JBoss JIRA] (ISPN-833) Revisit cache name predefinition limitation for cache servers
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-833?page=com.atlassian.jira.plugin.s... ]
Galder Zamarreño updated ISPN-833:
----------------------------------
Fix Version/s: 7.0.0.Alpha1
7.0.0.Final
> Revisit cache name predefinition limitation for cache servers
> -------------------------------------------------------------
>
> Key: ISPN-833
> URL: https://issues.jboss.org/browse/ISPN-833
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches:
> 1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days.
> 2. Infinispan has issues dealing with asymmetric clusters (ISPN-658).
> Once these two issues have been resolved, revisit the limitation.
--
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, 1 month
[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3530:
----------------------------------------
As part of the changes required to add segment support (ISPN-3529), I'll be implementing these changes in the Java Hot Rod client so that it keeps a per cache CH instead of a global one.
> The HotRod client should support a separate CH for each cache
> -------------------------------------------------------------
>
> Key: ISPN-3530
> URL: https://issues.jboss.org/browse/ISPN-3530
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Affects Versions: 6.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha1
>
>
> With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH.
> In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache.
--
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, 1 month