March 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1928) Listner Callback once CACHE is expired

by senthil senthil (JIRA)

senthil senthil created ISPN-1928: ------------------------------------- Summary: Listner Callback once CACHE is expired Key: ISPN-1928 URL: https://issues.jboss.org/browse/ISPN-1928 Project: Infinispan Issue Type: Feature Request Components: Cache Server Affects Versions: 5.1.2.FINAL Reporter: senthil senthil Assignee: Manik Surtani Listner Callback once CACHE is expired, this will help users to reload the data on cache on timed basis. for example , user specific message data is reloaded every 3 mins so that user will be notified. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] (ISPN-1915) Memory leak in L1 manager

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1915: ----------------------------------- Summary: Memory leak in L1 manager Key: ISPN-1915 URL: https://issues.jboss.org/browse/ISPN-1915 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.2.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Priority: Blocker Fix For: 5.1.x >From an email from Bela: {quote} OK, when running async DIST with 2 nodes and numOwners == 2, I found a huge memory leak in the L1ManagerImpl ! With L1 enabled, my test with 1 passive and 1 active node wouldn't complete with 10 threads each putting 100'000 elements in the cache; instead the passive node would always OOME ! With L1 disabled, it would complete, with 23'000 TXs / sec ! Profiling the passive node (the one which would receive the modifications via RPCs), I can see that L1ManageImpl.addRequestor() leaks entries in the 'requestors' hashmap. ****** The weird thing is that L1 shouldn't even matter in the 2 node case ! ****** {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

12 years, 9 months

3
6
0 / 0

[JBoss JIRA] (ISPN-1922) Old configuration API bug hiding a NPE in VersionedEntryWrappingInterceptor

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1922: -------------------------------------- Summary: Old configuration API bug hiding a NPE in VersionedEntryWrappingInterceptor Key: ISPN-1922 URL: https://issues.jboss.org/browse/ISPN-1922 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.2.FINAL Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.1.3.CR1, 5.1.3.FINAL While doing ISPN-1367 and converting the internals to new configuration, I've found two bugs. Basically, there's a bug in the old configuration (I'll open another jira for this...) that makes FlagsEnabledTest pass when it shouldn't. To be precise, that test enables configuration such as: {code}.versioning().enable().scheme(VersioningScheme.SIMPLE){code} But, in the InterceptorChainFactory, needsVersionAwareComponents returns false (configuration.isEnableVersioning() = false): {code}boolean needsVersionAwareComponents = configuration.isTransactionalCache() && configuration.isWriteSkewCheck() && configuration.getTransactionLockingMode() == LockingMode.OPTIMISTIC && configuration.isEnableVersioning();{code} By changing the internals to the config, the configuration.isEnableVersioning() returns true and so FlagsEnabledTest.testWithFlagsSemantics fails with: {code}2012-03-16 15:12:42,337 ERROR [InvocationContextInterceptor] (main) ISPN000136: Execution error java.lang.NullPointerException at org.infinispan.interceptors.VersionedEntryWrappingInterceptor.commitContextEntry(VersionedEntryWrappingInterceptor.java:94) at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:271) at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:182) at org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitCommitCommand(VersionedEntryWrappingInterceptor.java:87) at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:66) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:121) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitCommitCommand(AbstractTxLockingInterceptor.java:105) at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:66) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.NotificationInterceptor.visitCommitCommand(NotificationInterceptor.java:65) at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:66) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.TxInterceptor.visitCommitCommand(TxInterceptor.java:120) at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:66) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207) at org.infinispan.interceptors.StateTransferLockInterceptor.visitCommitCommand(StateTransferLockInterceptor.java:120) at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:66) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:89) at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:121) at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:66) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:182) at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:125) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:667) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2283) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1466) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:955) at org.infinispan.CacheImpl.put(CacheImpl.java:659) at org.infinispan.DecoratedCache.put(DecoratedCache.java:319) at org.infinispan.api.flags.FlagsEnabledTest.testWithFlagsSemantics(FlagsEnabledTest.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597){code} -- 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, 9 months

1
8
0 / 0

[JBoss JIRA] (ISPN-1907) Infinispan swallowing exceptions when attempting to instantiate invalid cache loader defined in xml

by Michael Mogley (JIRA)

Michael Mogley created ISPN-1907: ------------------------------------ Summary: Infinispan swallowing exceptions when attempting to instantiate invalid cache loader defined in xml Key: ISPN-1907 URL: https://issues.jboss.org/browse/ISPN-1907 Project: Infinispan Issue Type: Feature Request Components: Configuration Affects Versions: 5.1.2.FINAL, 5.2.0.FINAL Environment: Windows XP SP3, Oracle JDK 6 patch 31 Reporter: Michael Mogley Assignee: Manik Surtani When using the SpringEmbeddedCacheManagerFactoryBean, any exception that occurs when attempting to instantiate a CacheStore implementation do not bubble up to the log, even with full error logging turned on. A specific failure case is inadvertently defining the CacheStore implementation property setter method with 'private' scope. Being able to see the error in the log would allow for much quicker diagnosis and resolution of the underlying issue in the implementation. Right now, the only way to find such issue - other than to simply have it jump out at you in the CacheStore implementation code - is to step through the marshalling process in the Infinispan source itself. -- 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, 9 months

2
13
0 / 0

[JBoss JIRA] (ISPN-1879) Add RSVP message flag to state transfer RPCs

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1879: ----------------------------------- Summary: Add RSVP message flag to state transfer RPCs Key: ISPN-1879 URL: https://issues.jboss.org/browse/ISPN-1879 Project: Infinispan Issue Type: Enhancement Components: State transfer Affects Versions: 5.1.1.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.2.CR1, 5.1.2.FINAL This is specific to JGroups 3.1.x, and allows UNICAST2 to detect the missing final packet when performing a state transfer -- 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, 9 months

3
9
0 / 0

[JBoss JIRA] (ISPN-1918) Benchmark UNICAST vs UNICAST2 vs NAKACK2 with JGroups 3.0.x

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1918: ---------------------------------- Summary: Benchmark UNICAST vs UNICAST2 vs NAKACK2 with JGroups 3.0.x Key: ISPN-1918 URL: https://issues.jboss.org/browse/ISPN-1918 Project: Infinispan Issue Type: Task Components: RPC Affects Versions: 5.1.2.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.3.CR1, 5.1.3.FINAL Recent changes seem to have brought performance a bit down, so we need to check whether this is caused by reverting to UNICAST instead of UNICAST2 (ISPN-1892). Performance has decreased most in the 2-node scenario, where we were actually sending multicasts instead of unicasts. So we need to check whether there is a performance difference between UNICAST2 and NAKACK2 as well. If we find UNICAST2 to perform better, we can proceed with ISPN-1879 on the 5.1.x branch as well as on the master branch. -- 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, 9 months

1
4
0 / 0

[JBoss JIRA] (ISPN-1931) The command retry mechanism in StateTransferLockInterceptor doesn't work properly if a target node died

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1931: ---------------------------------- Summary: The command retry mechanism in StateTransferLockInterceptor doesn't work properly if a target node died Key: ISPN-1931 URL: https://issues.jboss.org/browse/ISPN-1931 Project: Infinispan Issue Type: Bug Components: RPC Affects Versions: 5.1.2.CR1, 5.1.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL, 5.1.2.FINAL When one of a command's target nodes leaves the cluster, StateTransferLockInterceptor is supposed to catch the SuspectException and retry the command. This mechanism doesn't work, because the SuspectException is wrapped inside a CacheException. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] (ISPN-1837) Add support for configuration file based configuration override

by William Burns (JIRA)

William Burns created ISPN-1837: ----------------------------------- Summary: Add support for configuration file based configuration override Key: ISPN-1837 URL: https://issues.jboss.org/browse/ISPN-1837 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.0.FINAL Reporter: William Burns Assignee: Manik Surtani I totally like the new configuration changes. However one thing that was available before was a way to allow for overrides of configuration to occur from multiple configuration files. This was available with the defineConfiguration method on the CacheManager. This is how I was able to do this in the past and it worked great. {code} for (File file : files) { InfinispanConfiguration readConfig = ...; cacheManager.getDefaultConfiguration().applyOverrides(readConfig.parseDefaultConfiguration()); for (Entry<String, Configuration> entry : readConfig.parseNamedConfigurations().entrySet()) { cacheManager.defineConfiguration(entry.getKey(), entry.getValue()); } } {code} This ability was taken away and the replacement is to use the read method on the various ConfigurationBuilders. This works great for programmatic override of various values. However there is no easy way to do overrides based on a configuration file. This is due to the fact that the only way a user can get ConfigurationBuilder objects from a configuration file is with all the default values provided. Thus you are basically replacing a configuration instead of overriding it. I wanted to propose a simple change to the Parser class so it can now also take a ConfigurationBuilderHolder so then a user can retain their own holder and pass it on to subsequent parse calls. This way only the values read from the parser will be set on the configuration builder objects. With t his small change I am then able to do the following: {code} Parser parser = new Parser(Thread.currentThread().getContextClassLoader()); for (File file : files) { parser.parse(file.getAbsolutePath(), holder); } {code} Also a side note but the way the transport is handled right now kind of throws a wrench in this. I noticed that if the global section is provied if no transport is in the xml it will null out the transport in the configuration on the override. This can be problematic if the transport is defined in a starting xml file and later a different xml file may want to say add some additional externalizers or something (which we do) and then the transport will be set to null. Right now I am working around this by overriding the transport last, but would be nice if I didn't have to do that. I could also define an empty transport element in all of the xml files to workaround it as well. The transport issue occurs because of line 1209 in the Parser class. I don't know if it can be changed without breaking something else and as such didn't include it in my pull request, but would be nice if this could also be changed. {code} if (!transportParsed) { // make sure there is no "default" transport builder.transport().transport(null); } {code} -- 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, 9 months

4
5
0 / 0

[JBoss JIRA] (ISPN-1899) Misleading error message when configuration file is not found

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-1899: ------------------------------------- Summary: Misleading error message when configuration file is not found Key: ISPN-1899 URL: https://issues.jboss.org/browse/ISPN-1899 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.2.FINAL Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 5.2.0.ALPHA1 If the configuration filename is wrong (or file is missing), you get an "com.ctc.wstx.exc.WstxIOException: Stream closed" exception. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] (ISPN-1932) Upgrade to JGroups 3.0.8.FINAL

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1932: ---------------------------------- Summary: Upgrade to JGroups 3.0.8.FINAL Key: ISPN-1932 URL: https://issues.jboss.org/browse/ISPN-1932 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.2.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.3.FINAL JGroups 3.0.8 contains a backport of the RSVP protocol, which is required for us to upgrade back to UNICAST2 (ISPN-1879). -- 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, 9 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2012