November 2011 - infinispan-issues

[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

13 years, 10 months

6
10
0 / 0

[JBoss JIRA] (ISPN-1517) LockBreakingService not stopping

by Galder Zamarreño (Created) (JIRA)

LockBreakingService not stopping -------------------------------- Key: ISPN-1517 URL: https://issues.jboss.org/browse/ISPN-1517 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.BETA4 Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.1.0.BETA5 A thread dump taken towards the end of the testsuite shows a lot of: "LockBreakingService,___defaultcache,LockOwnerCrashPessimisticReplTest-NodeB-4905" daemon prio=5 tid=7fce6f753800 nid=0x11b9e6000 waiting on condition [11b9e5000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) I don't see where StaleTransactionCleanupService.stop() is being called, so it appears those services are never stopped and it does not have @Stop or anything similar on it. -- 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

13 years, 10 months

6
6
0 / 0

[JBoss JIRA] (ISPN-1537) Re-enable OSGi bundles when split packages are handled correctly

by Tristan Tarrant (Created) (JIRA)

Re-enable OSGi bundles when split packages are handled correctly ---------------------------------------------------------------- Key: ISPN-1537 URL: https://issues.jboss.org/browse/ISPN-1537 Project: Infinispan Issue Type: Task Components: Build process Affects Versions: 5.1.0.BETA5 Reporter: Tristan Tarrant Assignee: Tristan Tarrant When https://issues.apache.org/jira/browse/FELIX-3238 is fixed, we should re-enable the OSGi bundles -- 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

13 years, 10 months

4
3
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

13 years, 10 months

4
10
0 / 0

[JBoss JIRA] (ISPN-1563) Cache configured with the new configuration always returns null values

by Kevin Pollet (Created) (JIRA)

Cache configured with the new configuration always returns null values ---------------------------------------------------------------------- Key: ISPN-1563 URL: https://issues.jboss.org/browse/ISPN-1563 Project: Infinispan Issue Type: Bug Components: CDI integration Reporter: Kevin Pollet Assignee: Pete Muir Priority: Blocker Fix For: 5.0.2.FINAL The test case: {quote} DefaultCacheManager cacheManager = new DefaultCacheManager(new ConfigurationBuilder().build()); Cache<String, String> cache = cacheManager.getCache(); cache.put("Foo", "2"); cache.put("Bar", "4"); System.out.println(cache.get("Foo")); System.out.println(cache.get("Bar")); {quote} -- 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

13 years, 10 months

4
3
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

13 years, 10 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

13 years, 10 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

13 years, 10 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

13 years, 10 months

3
6
0 / 0

[JBoss JIRA] (ISPN-1567) createHotRodServers() from org.infinispan.client.hotrod.test.MultiHotRodServersTest crashes when using replication queue

by Jozef Vilkolak (Created) (JIRA)

createHotRodServers() from org.infinispan.client.hotrod.test.MultiHotRodServersTest crashes when using replication queue ------------------------------------------------------------------------------------------------------------------------ Key: ISPN-1567 URL: https://issues.jboss.org/browse/ISPN-1567 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.1.0.BETA5 Reporter: Jozef Vilkolak Assignee: Galder Zamarreño When a class extends MultiHotRodServersTest and tries to use createHotRodServers to create 2 servers with REPL_ASYNC and useReplQueue configurations, it crashes on the error message "Use of the replication queue is only allowed with an ASYNCHRONOUS cluster mode." {code:xml} Configuration config = new Configuration().fluent() .clustering() .mode(CacheMode.REPL_ASYNC) .async() .replQueueInterval(1000L) .useReplQueue(true) .eviction() .maxEntries(3) .build(); createHotRodServers(2, config); {code} I think this happens because in HotRodServer in method createTopologyCacheConfig REPL_SYNC is set but replication queue is not disabled. -- 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

13 years, 10 months

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2011