October 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-555) Remote nodes should have a user cfg timeout before heuristic rollback

by Mircea Markus (JIRA)

Remote nodes should have a user cfg timeout before heuristic rollback --------------------------------------------------------------------- Key: ISPN-555 URL: https://jira.jboss.org/browse/ISPN-555 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.BETA1 This is code in TransactionTable.StaleTransactionCleanup. This is because the failing might get restarted and it can finish the transaction in a coordinated, non-heuristic manner. -- 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, 5 months

4
10
0 / 0

[JBoss JIRA] (ISPN-1473) Upgrade to RHQ 3.0.1

by Galder Zamarreño (Created) (JIRA)

Upgrade to RHQ 3.0.1 -------------------- Key: ISPN-1473 URL: https://issues.jboss.org/browse/ISPN-1473 Project: Infinispan Issue Type: Component Upgrade Components: JMX, reporting and management Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.CR1 Currently we have RHQ plugin annotations on 3.0.1 and RHQ on 3.0.0. Align on 3.0.1 -- 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, 5 months

5
6
0 / 0

[JBoss JIRA] Created: (ISPN-1317) JGroupsDistSync.flushWaitGate appears to be left open

by Galder Zamarreño (JIRA)

JGroupsDistSync.flushWaitGate appears to be left open ----------------------------------------------------- Key: ISPN-1317 URL: https://issues.jboss.org/browse/ISPN-1317 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.0.0.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL Logs in JBPAPP-6929 show: {code}15:40:22,698 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (STREAMING_STATE_TRANSFER-sender-1,default,michal-linhard-12702) ISPN000095: Caught while responding to state transfer request: org.infinispan.statetransfer.StateTransferException: java.util.concurrent.TimeoutException: Timed out waiting for a cluster-wide sync to be acquired. (timeout = 60 seconds) at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:162) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT] at org.infinispan.remoting.InboundInvocationHandlerImpl.generateState(InboundInvocationHandlerImpl.java:248) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.getState(JGroupsTransport.java:590) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:690) [jgroups-2.12.1.Final.jar:] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:771) [jgroups-2.12.1.Final.jar:] at org.jgroups.JChannel.up(JChannel.java:1484) [jgroups-2.12.1.Final.jar:] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1074) [jgroups-2.12.1.Final.jar:] at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:477) [jgroups-2.12.1.Final.jar:] at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderHandler.process(STREAMING_STATE_TRANSFER.java:651) [jgroups-2.12.1.Final.jar:] at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderThreadSpawner$1.run(STREAMING_STATE_TRANSFER.java:580) [jgroups-2.12.1.Final.jar:] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_25] at java.lang.Thread.run(Thread.java:662) [:1.6.0_25] Caused by: java.util.concurrent.TimeoutException: Timed out waiting for a cluster-wide sync to be acquired. (timeout = 60 seconds) at org.infinispan.remoting.transport.jgroups.JGroupsDistSync.blockUntilAcquired(JGroupsDistSync.java:62) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT] at org.infinispan.statetransfer.StateTransferManagerImpl.generateTransactionLog(StateTransferManagerImpl.java:196) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT] at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:152) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT] ... 12 more{code} Now, what's odd about this is that the JGroupsDistSync.flushWaitGate behind it is only acquired/released while state transfer control command is sent and the logs show that both the enabling(acquiring) and disabling(releasing) state transfer control commands where built: {code}15:39:20,902 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) dests=[michal-linhard-37465], command=StateTransferControlCommand{enabled=true}, mode=SYNCHRONOUS, timeout=480000 ... 15:39:21,074 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) dests=[michal-linhard-37465], command=StateTransferControlCommand{enabled=false}, mode=SYNCHRONOUS, timeout=480000{code} There's no other references to StateTransferControlCommand, so how can it be that flushWaitGate is open? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
9
0 / 0

[JBoss JIRA] Created: (ISPN-1298) Configure fork=once so that TRACE logs can be gathered more easily

by Galder Zamarreño (JIRA)

Configure fork=once so that TRACE logs can be gathered more easily ------------------------------------------------------------------ Key: ISPN-1298 URL: https://issues.jboss.org/browse/ISPN-1298 Project: Infinispan Issue Type: Enhancement Components: Test Suite Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 5.2.0.FINAL We currently run our testsuite with fork=none which causes us some small issues: - First, we're exposed to whatever system properties Maven might use internally which could impact our build. - Secondly, it makes it difficult to have per-project log4j settings that are not hardcoded in the source code. So, what is suggested here is that we switch to fork=once so that each module's testsuite runs in a different JVM. The overhead of this is apparently pretty small (needs double checking). In terms of logging, this potentially enables each module to have its own 'trace-enabling' profile pointing to its own TRACE enabled log4j file, making it quite easy for each module to define what TRACE is relevant for each. For example: {code} <project> <profiles> <profile> <id>trace-tests</id> <build> <plugins> <plugin> <artifactId>maven-surefire-plugin</artifactId> <configuration> <systemPropertyVariables> <log4j.configuration>${basedir}/src/test/trace/log4j.xml</log4j.configuration> </systemPropertyVariables> </configuration> </plugin> </plugins> </build> </profile> </profiles> </project> {code} This has another advantage which is allowing us to override the log output directory selectively which is handy in a CI environment such as CloudBees: - First, set the logs location to be dependant on another system property, i.e.: {code}location=${log4j.outputDirectory}/infinispan.log{code} - And then, selectively change it: {code}<systemPropertyVariables> <log4j.configuration>${basedir}/src/test/trace/log4j.xml</log4j.configuration> <log4j.outputDirectory>${project.build.directory}/test-logs</log4j.outputDirectory> </systemPropertyVariables>{code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-465) HTTP session management for Tomcat

by Manik Surtani (JIRA)

HTTP session management for Tomcat ---------------------------------- Key: ISPN-465 URL: https://jira.jboss.org/browse/ISPN-465 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final Session management plugin for Glassfish, to allow running Glassfish in non-clustered mode and having all clustering of session state managed by Infinispan. -- 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, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-1297) add option to enable 1PC for induced transactions

by Mircea Markus (JIRA)

add option to enable 1PC for induced transactions ------------------------------------------------- Key: ISPN-1297 URL: https://issues.jboss.org/browse/ISPN-1297 Project: Infinispan Issue Type: Feature Request Components: Configuration, Transactions Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL Starting with Infinispan 5.1 a cache is only able to function in either transactional or non-transactional mode. Mixed mode won't be supported any more. This is causing a backward compatibility issue for existing users that make both transactional and non-transactional access to the same cache. A good example is the Lucene-directory that is writing to a cache through batching API *and* directly. In Lucene-D's case, one can configure autoCommit=true for a transaction: that will induce a transaction within direct (i.e. non transactional) calls. Whilst this preserves backward compatibility, it is not "good enough" as an injected transaction does results in 2 RPCs, one for each phase of 2PC, and that is less performant than the "old" direct call. In order to solve this performance shortcoming, another attribute is to be added: use1PcForInducedTransaction(default to true). Enabling this attribute causes the *induced* transaction to force an 1PC resulting in a single RPC. Other tx that induced one won't be affected by this configuration. This mail thread is also relevant: http://bit.ly/plNbLT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

8
17
0 / 0

[JBoss JIRA] Created: (ISPN-1391) Use UNICAST2 instead of UNICAST

by Galder Zamarreño (JIRA)

Use UNICAST2 instead of UNICAST ------------------------------- Key: ISPN-1391 URL: https://issues.jboss.org/browse/ISPN-1391 Project: Infinispan Issue Type: Enhancement Components: RPC Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.1.0.BETA2, 5.1.0.FINAL UNICAST2 already available in JGroups 2.12: http://www.jgroups.org/javadoc/org/jgroups/protocols/UNICAST2.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
8
0 / 0

[JBoss JIRA] Created: (ISPN-1130) Eager locks acquired multiple times

by Mircea Markus (JIRA)

Eager locks acquired multiple times ----------------------------------- Key: ISPN-1130 URL: https://issues.jboss.org/browse/ISPN-1130 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Manik Surtani If eager locking is enabled, a remote lock is acquired repeatedly. e.g. tx.begin() cache.put(k,v); //rpc acquiring lock on "k" ... cache.remove(k); // another rpc for acquiring lock on "k" tx.commit(); the second rpc for acquiring lock is un-necessary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
13
0 / 0

[JBoss JIRA] Created: (ISPN-1397) Optimise thread local usage in Infinispan

by Manik Surtani (JIRA)

Optimise thread local usage in Infinispan ----------------------------------------- Key: ISPN-1397 URL: https://issues.jboss.org/browse/ISPN-1397 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.FINAL Three separate areas to consider: 1. Remove ThreadLocal usage in OwnableReentrantLock 2. Remove ThreadLocal usage in InvocationContextContainer 3. Remove ThreadLocal usage in Flags API Look for any other ThreadLocal usage with a critical eye. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

7
11
0 / 0

[JBoss JIRA] Created: (ISPN-1415) timeouts on startCaches on repl caches

by Sanne Grinovero (JIRA)

timeouts on startCaches on repl caches -------------------------------------- Key: ISPN-1415 URL: https://issues.jboss.org/browse/ISPN-1415 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.ALPHA2 , 5.0.1.FINAL, 5.0.0.FINAL Reporter: Sanne Grinovero Assignee: Dan Berindei Fix For: 5.0.2.FINAL, 5.1.0.BETA1 The failing branch on Hibernate Search is committed at https://github.com/Sanne/hibernate-search/tree/startCaches -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2011