[JBoss JIRA] (ISPN-1818) Get rid of commons-pool for Hot Rod client
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-1818:
--------------------------------------
Summary: Get rid of commons-pool for Hot Rod client
Key: ISPN-1818
URL: https://issues.jboss.org/browse/ISPN-1818
Project: Infinispan
Issue Type: Enhancement
Components: Cache Server
Affects Versions: 5.2.0.ALPHA1, 5.2.0.FINAL
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Get rid of commons-pool in Hot Rod client. We can implement connection pooling with thread locals and a ringed array if re-entrant connection request are needed. This has the benefit of getting rid an unnecessary dependency, and thread locals have been proved previously (i.e. with marshallers) to provide very good solutions for reusing expensive resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-1831) Cannot configure hotRodClientProperties programmatically.
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-1831:
----------------------------------
Summary: Cannot configure hotRodClientProperties programmatically.
Key: ISPN-1831
URL: https://issues.jboss.org/browse/ISPN-1831
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 5.1.1.CR1
Reporter: Paul Ferraro
Assignee: Manik Surtani
Priority: Critical
Fix For: 5.1.1.FINAL
Currently, there's no way to configure hotRotClientProperties programatically via the configuration API. Since there's no builder for a remote cache store, we need to use the generic one. hotRodClientProperties cannot be specified as a property, since it has no corresponding property editor, which is required when translating the CacheLoaderConfiguratoinBuilder to the legacy counterpart.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-1890) Unable to create new native thread when running core/ testsuite
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-1890:
--------------------------------------
Summary: Unable to create new native thread when running core/ testsuite
Key: ISPN-1890
URL: https://issues.jboss.org/browse/ISPN-1890
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Reporter: Galder Zamarreño
Assignee: Mircea Markus
Fix For: 5.1.2.FINAL
Suddenly, running core/ testsuite only with -Xmx768m -XX:MaxPermSize=256M, I'm seeing:
{code}Test suite progress: tests succeeded: 1695, failed: 4, skipped: 0.
Exception in thread "ConnectionMap.Acceptor,null,null" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.start(TCPConnectionMap.java:568)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.start(TCPConnectionMap.java:411)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$600(TCPConnectionMap.java:354)
at org.jgroups.blocks.TCPConnectionMap$ConnectionAcceptor.run(TCPConnectionMap.java:259)
at java.lang.Thread.run(Thread.java:680)
Exception in thread "ConnectionMap.Acceptor,null,null" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.start(TCPConnectionMap.java:568)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.start(TCPConnectionMap.java:411)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$600(TCPConnectionMap.java:354)
at org.jgroups.blocks.TCPConnectionMap$ConnectionAcceptor.run(TCPConnectionMap.java:259)
at java.lang.Thread.run(Thread.java:680)
Exception in thread "ConnectionMap.Acceptor,null,null" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.start(TCPConnectionMap.java:568)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.start(TCPConnectionMap.java:411)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$600(TCPConnectionMap.java:354)
at org.jgroups.blocks.TCPConnectionMap$ConnectionAcceptor.run(TCPConnectionMap.java:259)
at java.lang.Thread.run(Thread.java:680)
[testng-TopologyAwareDistAsyncFuncTest] Test testPutIfAbsentFromNonOwner(org.infinispan.distribution.topologyaware.TopologyAwareDistAsyncFuncTest) succeeded.
Test suite progress: tests succeeded: 1696, failed: 4, skipped: 0.
[testng-TopologyAwareDistAsyncFuncTest] Test testRemoveFromNonOwner(org.infinispan.distribution.topologyaware.TopologyAwareDistAsyncFuncTest) succeeded.
Test suite progress: tests succeeded: 1697, failed: 4, skipped: 0.
[testng-TopologyAwareDistAsyncFuncTest] Test testReplaceFromNonOwner(org.infinispan.distribution.topologyaware.TopologyAwareDistAsyncFuncTest) succeeded.
Test suite progress: tests succeeded: 1698, failed: 4, skipped: 0.
Exception in thread "CacheViewTrigger,TopologyAwareDistAsyncFuncTest-NodeA-38647" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(ThreadPoolExecutor.java:727)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:657)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewTriggerThread.run(CacheViewsManagerImpl.java:848){code}
See attached thread dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-1838) State transfer takes more than 10 minutes with only 10K entries.
by Michal Linhard (JIRA)
Michal Linhard created ISPN-1838:
------------------------------------
Summary: State transfer takes more than 10 minutes with only 10K entries.
Key: ISPN-1838
URL: https://issues.jboss.org/browse/ISPN-1838
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.1.1.CR1
Reporter: Michal Linhard
Assignee: Manik Surtani
This could be categorized as a performance problem.
It happened in resilience test run: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j...
originally to verify ISPN-1826
It was run with infinispan special build from Galder's branch (https://github.com/galderz/infinispan/tree/t_1826_5)
http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-build-...
test starts 4 nodes, kills node2, starts node2 and sees what happens
trace logging on server side was on. there were two runs
200 clients, 10K entries
http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j...
20 clients, 1K entries
http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j...
in run 24 everyting looks nice:
http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j...
in run 23 the state transfer takes forever (more than 10 min)
these important views are installed on coordinator (node03):
{code}
2012-02-02 05:11:00,560 TRACE [BaseStateTransferManagerImpl] (transport-thread-1) Received new cache view: testCache CacheView{viewId=6, members=[edg-perf04-45788, edg-perf03-36944, edg-perf02-51026, edg-perf01-47003]}
2012-02-02 05:15:13,591 TRACE [BaseStateTransferManagerImpl] (transport-thread-9) Received new cache view: testCache CacheView{viewId=7, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003]}
2012-02-02 05:18:17,219 TRACE [BaseStateTransferManagerImpl] (transport-thread-1) Received new cache view: testCache CacheView{viewId=8, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003, edg-perf02-21799]}
2012-02-02 05:28:17,511 TRACE [BaseStateTransferManagerImpl] (transport-thread-22) Received new cache view: testCache CacheView{viewId=10, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003, edg-perf02-21799]}
{code}
viewId=8 is the one that takes 10 min to prepare and after that the prepare fails:
{code}
2012-02-02 05:28:17,219 ERROR [CacheViewsManagerImpl] (CacheViewInstaller-9,edg-perf03-36944) ISPN000172: Failed to prepare view CacheView{viewId=8, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003, edg-perf02-21799]} for cache testCache, ro..
java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228)
at java.util.concurrent.FutureTask.get(FutureTask.java:91)
at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:319)
at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:250)
at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:877)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
{code}
viewId=10 is a retry and that succeeds quite quickly but the test is already ending about that time.
It might be worth looking at the tracelogs since they're already there...
10K entries and 200 clients isn't such a big load ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
by Manik Surtani (JIRA)
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL: https://jira.jboss.org/browse/ISPN-586
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores, Transactions
Affects Versions: 4.1.0.CR2
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 4.1.0.CR3
>From the reporter:
"Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain.
This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix."
This possibly has to do with the AbstractCacheStore doing the following in prepare():
"
public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
if (isOnePhase) {
applyModifications(mods);
} else {
transactions.put(tx, mods);
}
}
"
and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-1799) We should avoid using exceptions for flow control when acquiring state transfer lock
by Dan Berindei (JIRA)
Dan Berindei created ISPN-1799:
----------------------------------
Summary: We should avoid using exceptions for flow control when acquiring state transfer lock
Key: ISPN-1799
URL: https://issues.jboss.org/browse/ISPN-1799
Project: Infinispan
Issue Type: Task
Components: State transfer
Affects Versions: 5.1.0.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.2.0.FINAL
We currently use `StateTransferInProgressException` as a marker that a write command failed to acquire the state transfer lock and it should be retried. With ISPN-1704 I added another exception, StateTransferLockReacquisitionException, to signal that a write command failed to re-acquire the state transfer lock after it had already acquired it.
These exceptions often appear in the logs and confuse users (see ISPN-1610), so it would be best to use special return values. We may also need a flag in the InvocationContext for StateTransferLockReacquisitionException.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-1588) IndexOutOfBoundsException while using clustered query
by Mathieu Lachance (Created) (JIRA)
IndexOutOfBoundsException while using clustered query
-----------------------------------------------------
Key: ISPN-1588
URL: https://issues.jboss.org/browse/ISPN-1588
Project: Infinispan
Issue Type: Bug
Components: Querying, RPC
Affects Versions: 5.1.0.BETA5
Reporter: Mathieu Lachance
Assignee: Sanne Grinovero
when using clustered query with dist sync mode i'm running into index out of bound exception.
java.lang.IndexOutOfBoundsException: Index: 100, Size: 100
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at org.infinispan.query.clustered.DistributedIterator.current(DistributedIterator.java:138)
at org.infinispan.query.clustered.DistributedIterator.next(DistributedIterator.java:114)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.list(ClusteredCacheQueryImpl.java:136)
at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:239)
at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:200)
at com.XXX.ClientCache.getClientsByServerId(ClientCache.java:168)
at com.XXX.getClientsByServerId(ClientManager.java:157)
at com.XXX$PingClient.run(PlayerBll.java:890)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
i do not have any reproductible step, but here's what i know :
it only seems to happen under high contention ; when i'm running stress test.
when running a stress test i might get query that return over than 100 results.
tough i've also seen it happen on query that can only return few (4-6) results.
i never saw the stack trace with different index and size different than 100 (it's always the exact same exception).
i've also tried the lazy iterator to see if it would have a different behavior, but i get the same stack trace.
is there anything i could look up in the source code to debug and maybe find the repro steps ?
thanks,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
