August 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-385) Add idle timeout to memcached and hot rod servers.

by Galder Zamarreno (JIRA)

Add idle timeout to memcached and hot rod servers. -------------------------------------------------- Key: ISPN-385 URL: https://jira.jboss.org/jira/browse/ISPN-385 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Add an IdleStateHandler to memcached and hot rod servers so that idle connections can be closed automatically. This is necessary to handle error conditions such as cases where clients erroneously indicate the server that it needs to read 20 bytes but they only send 10 bytes. Without such handler, the server will carry on waiting for bytes forever. The handler will provide a defence mechanism for such cases. The timeout will be configurable via the command line. Besides, clients wanting to do some connection pooling will require to configure this accordingly in the server. In other words, there's hardly any point in having servers configured with idle timeout of 30 seconds and clients closing connections after 60 seconds of idle time. These two should be aligned accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1303) More FileCacheStore optimizations

by Robert Stupp (JIRA)

More FileCacheStore optimizations --------------------------------- Key: ISPN-1303 URL: https://issues.jboss.org/browse/ISPN-1303 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 5.0.0.CR8 Reporter: Robert Stupp Assignee: Manik Surtani Still some more optimizations 1. added a check to prohibit purge at all, if the whole cache store does not contain any expireable cache entry (works great with non-expireable cache entries - like Lucene indexes) 2. added some more configuration options for purge: 2.a. minimum time to wait between to purge runs 2.b. minimum time to wait after last update to a bucket before purge run 2.c. maximum time to wait after the last purge run 3. prohibit purge run, if no update occured 4. prohibit purge test (and execution), if bucket file did not change after last purge run Will attach source code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1265) Use alternative/default bean to allow overriding of the default cache configuration and default cache manager

by Kevin Pollet (JIRA)

Use alternative/default bean to allow overriding of the default cache configuration and default cache manager ------------------------------------------------------------------------------------------------------------- Key: ISPN-1265 URL: https://issues.jboss.org/browse/ISPN-1265 Project: Infinispan Issue Type: Task Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Fix For: 5.1.0.FINAL To allow the user to override the default cache configuration and the default cache manager we need to use alternative/default bean (it's more in the CDI spirit). Because of a couple of bugs with DefaultBean it's not possible at the moment but we need to use it asap. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1331) Log something about auto discovered modules and extensions

by Sanne Grinovero (JIRA)

Log something about auto discovered modules and extensions ---------------------------------------------------------- Key: ISPN-1331 URL: https://issues.jboss.org/browse/ISPN-1331 Project: Infinispan Issue Type: Feature Request Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.1.0.ALPHA1 It seems that when looking in the classpath for instances of _infinispan-module.properties_ files, nothing is logged. No idea why it's not loading an extension. Also specific modules should log their registration happening: _org.infinispan.tree.LifecycleCallbacks_ should mention that it's being enabled. (when registration of such a module doesn't happen, people experience misleading errors) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
10
0 / 0

[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] 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, 6 months

8
17
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, 6 months

6
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2011