July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2915) Deprecate JBossTransactionManagerLookup as it is redundant

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-2915?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-2915: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deprecate JBossTransactionManagerLookup as it is redundant > ---------------------------------------------------------- > > Key: ISPN-2915 > URL: https://issues.jboss.org/browse/ISPN-2915 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 5.2.1.Final > Reporter: Martin Gencur > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > JDNI lookups from JBossTransactionManagerLookup are all covered by the GenericTransactionManagerLookup. > Furthermore, the JBoss JNDI names are requested first in the GenericTML so there's is no point in having two different TransactioManager lookup classes serving the same purpose. > I suggest that we deprecate the JBossTransactionManagerLookup in the next release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1986) Make putForExternalRead return a boolean instead of void

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1986?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1986: ------------------------------------- [~sannegrinovero] unless it really kills performance, I don't consider this critical :-) > Make putForExternalRead return a boolean instead of void > -------------------------------------------------------- > > Key: ISPN-1986 > URL: https://issues.jboss.org/browse/ISPN-1986 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > Related to ISPN-1983 and https://hibernate.onjira.com/browse/HHH-7256, I'd like to change the API of putForExternalRead() to return a boolean instead of void. > The reason for doing this is to be able to find out if the PFER did actually end up storing something or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2719) Tx complete notification and prepare crossing leads to failed transaction

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2719?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2719: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.Alpha1) > Tx complete notification and prepare crossing leads to failed transaction > ------------------------------------------------------------------------- > > Key: ISPN-2719 > URL: https://issues.jboss.org/browse/ISPN-2719 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.0.CR2 > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.0.0.Final > > Attachments: testRemoteCacheListener-5.log > > > {code}testRemoteCacheListener(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.059 sec <<< FAILURE! > org.infinispan.CacheException: Could not commit implicit transaction > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1159) > at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:310) > at org.infinispan.CacheImpl.remove(CacheImpl.java:304) > at org.infinispan.CacheImpl.remove(CacheImpl.java:298) > at org.infinispan.replication.SyncCacheListenerTest.testRemoteCacheListener(SyncCacheListenerTest.java:113) > 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) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > 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) > at java.lang.Thread.run(Thread.java:680) > Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1156) > ... 25 more{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1856) Allow independent configuration of buffer allocation size vs segment chunks maximum size

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-1856?page=com.atlassian.jira.plugin.... ] Sanne Grinovero reassigned ISPN-1856: ------------------------------------- Assignee: Sanne Grinovero (was: Adrian Nistor) > Allow independent configuration of buffer allocation size vs segment chunks maximum size > ---------------------------------------------------------------------------------------- > > Key: ISPN-1856 > URL: https://issues.jboss.org/browse/ISPN-1856 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Final > > > Especially make sure that we can allocate buffers efficiently when having chunk_size=MAX_INTEGER or other very high values. > Maybe reuse them as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3109) Define(reuse) a language independent serialisation protocol for storing data in the cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3109?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3109: -------------------------------- Labels: jdg62 (was: ) > Define(reuse) a language independent serialisation protocol for storing data in the cache > ----------------------------------------------------------------------------------------- > > Key: ISPN-3109 > URL: https://issues.jboss.org/browse/ISPN-3109 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Adrian Nistor > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > The basic requirement is: write a Person object from a C++ hotrod client and read it from a Java/C# client, or in embedded mode. > Analysis: https://docs.google.com/spreadsheet/ccc?key=0Ag5RGdzR_GsldDdOVnpwbDUyT20x... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2402: -------------------------------- Priority: Major (was: Minor) > Cache operations or transactions should never fail with SuspectException > ------------------------------------------------------------------------ > > Key: ISPN-2402 > URL: https://issues.jboss.org/browse/ISPN-2402 > Project: Infinispan > Issue Type: Task > Components: RPC, State transfer > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: 5.2.x > Fix For: 6.0.0.Final > > Attachments: vrstt.log > > > This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user. > After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back). > For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2402: -------------------------------- Comment: was deleted (was: changed the priority to minor as the user should catch CacheException anyway and react to them.) > Cache operations or transactions should never fail with SuspectException > ------------------------------------------------------------------------ > > Key: ISPN-2402 > URL: https://issues.jboss.org/browse/ISPN-2402 > Project: Infinispan > Issue Type: Task > Components: RPC, State transfer > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: 5.2.x > Fix For: 6.0.0.Final > > Attachments: vrstt.log > > > This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user. > After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back). > For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1802) CacheEntryEvents with lazy loaded values

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1802?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1802: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > CacheEntryEvents with lazy loaded values > ---------------------------------------- > > Key: ISPN-1802 > URL: https://issues.jboss.org/browse/ISPN-1802 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.1.0.FINAL > Reporter: Thomas Fromm > Assignee: Manik Surtani > > Situation: I have listeners for CacheEntryEvents at every node and for every cache. > Some caches have entries with big values and I need at least the key. :-| > So listeners with lazily loaded values or just listeners for the keys, will be extremly useful for me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1802) CacheEntryEvents with lazy loaded values

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1802?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1802: -------------------------------- Priority: Minor (was: Major) > CacheEntryEvents with lazy loaded values > ---------------------------------------- > > Key: ISPN-1802 > URL: https://issues.jboss.org/browse/ISPN-1802 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.1.0.FINAL > Reporter: Thomas Fromm > Assignee: Manik Surtani > Priority: Minor > > Situation: I have listeners for CacheEntryEvents at every node and for every cache. > Some caches have entries with big values and I need at least the key. :-| > So listeners with lazily loaded values or just listeners for the keys, will be extremly useful for me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1441) Better and more sensible executor configuration

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1441?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1441: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Better and more sensible executor configuration > ----------------------------------------------- > > Key: ISPN-1441 > URL: https://issues.jboss.org/browse/ISPN-1441 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: executors > > Dan and I had a chat about ISPN-1396 and we both agreed that a better configuration and management approach is needed for Infinispan's executors: > - Firstly, out of the box for SE environments, Infinispan should have executors configured with newCachedThreadPool because they provide better queuing performance than a fixed thread pool. > - Sure, in an managed env (i.e. AS), this won't fly, which is why all executors need to be injectable. This should be in place once ISPN-1396 is in place. > - So, if we go for cached thread pools for SE environments, we don't need any of the properties of executors any more. Besides, these can be more confusing for the user (there is knowledged of at least one case where things went wrong due to bad config here). So, the configuration would be limited to injecting executors. If you need any specific executor settings, pass us the right executors. To aid these cases, we could have some executor builders available with some common executor configuration for managed envs (i.e. we could borrow settings from AS?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013