April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4082) TcpTransportFactory shouldn't log error when it cannot fetch transport

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4082?page=com.atlassian.jira.plugin.... ] Pedro Ruivo resolved ISPN-4082. ------------------------------- Assignee: Radim Vansa (was: Galder Zamarreño) Fix Version/s: 7.0.0.Alpha3 Resolution: Done > TcpTransportFactory shouldn't log error when it cannot fetch transport > ---------------------------------------------------------------------- > > Key: ISPN-4082 > URL: https://issues.jboss.org/browse/ISPN-4082 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 7.0.0.Alpha3 > > > With most HotRod operations being automatically retried when the connection fails, it's rather undesired to log errors each time one of the server fails - it confuses the users as if the application on client side did some error. > I believe that the verbosity of log.couldNotFetchTransport (used in TcpTransportFactory.borrowTransportFromPool) should be reduced to trace or debug level. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3920) Server initialization race condition - cache config defaults not used

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] Ion Savin commented on ISPN-3920: --------------------------------- Setting -Dorg.jboss.server.bootstrap.maxThreads=2 on the server will result in the same number of threads being used by JBoss MSC as when running on a single core machine. > Server initialization race condition - cache config defaults not used > --------------------------------------------------------------------- > > Key: ISPN-3920 > URL: https://issues.jboss.org/browse/ISPN-3920 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Ion Savin > Assignee: Ion Savin > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: server.log.gz > > > The [simple|https://github.com/infinispan/cpp-client/blob/master/test/Simple.cpp] HRCPP unit tests puts a key/value pair into the default cache and then retrives the value to make sure it's the same. Running the test on a single CPU machine against 6.0.0.Final causes the test to fail. > The root cause seems to be a race-condition in service initialization. The ProtocolServerServices are initialized (and create cache intances) before the CacheConfigurationServices finish loading the cache configuration defaults. Because of this AnyEquivalence is used for both keys and values instead of AnyServerEquivalence. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-1616) Provide removeAll bulk operation on Cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1616?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1616: ------------------------------------- Just to clarify Manik's last comment, if you're using optimistic tx caches, this optimisation takes place anyway. For pessimistic and non-tx caches it doesn't. > Provide removeAll bulk operation on Cache > ----------------------------------------- > > Key: ISPN-1616 > URL: https://issues.jboss.org/browse/ISPN-1616 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.1.0.CR1 > Reporter: Mathieu Lachance > Assignee: Manik Surtani > Priority: Minor > > is there any reason why api do not provide remove all operation, while there's lock(K...) putAll(Map<K,V>) operations ? > it would be great to add remove all capabilities to org.infinispan.Cache. > i guess it could also reduce the numbers of rpc calls in the following situation : > cache.getAdvancedCache().getTransactionManager().begin(); > cache.lock("a", "b", "c"); > cache.remove("a"); > cache.remove("b"); > cache.remove("c"); > cache.getAdvancedCache().getTransactionManager().commit(); > which could be re-implemented this way : > cache.getAdvancedCache().getTransactionManager().begin(); > cache.lock("a", "b", "c"); > cache.remove("a", "b", "c"); > cache.getAdvancedCache().getTransactionManager().commit(); -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4132) Group-based eviction

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4132?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-4132: ------------------------------------ "So at any time it might make sense to keep in memory some of the attributes of S, but not all of them." Not really. In WF/EAP, the sessions to be passivated are primarily expected to be abandoned sessions, that is, session that I expect to eventually expire. Our primary use case for passivation is *not* as a means to handle more active sessions that a given server can keep in memory - but rather to handle the abandoned, but not yet expired sessions. In this way, I would typically prefer to evict all entries of a presumably abandoned session over the attributes of an active session that have not been accessed recently. The likelihood that the former will be accessed before the latter is typically low. But no, there isn't anything in the JEE standard about how one specifies how sessions are passivated. Your point about this being too complex is certainly valid, so let's try a different tack... What if we had the ability to specify that a given cache entry was never to be passivated automatically (i.e. like an immortal cache entry, but for eviction purposes)? Infinispan would then passivate based on a max-size of "auto-evictable" cache entries (i.e. some subset of the total entries in memory). This way, I can leverage a passivation callback to manually passivate the non-auto-evictable session attributes for a given session and still be able to define my eviction settings based on a maximum number of sessions. WDYT? > Group-based eviction > -------------------- > > Key: ISPN-4132 > URL: https://issues.jboss.org/browse/ISPN-4132 > Project: Infinispan > Issue Type: Feature Request > Components: Eviction > Affects Versions: 6.0.2.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > > Currently, Infinispan only supports size-based eviction. We can configure a cache with a specific max-entries, so if the size exceeds this value infinispan will evict any surplus entries. > However, if the cache has grouping enabled, it is perhaps more useful to use group-based eviction. In this scenario, max-entries would be interpreted as "max-groups", and infinispan would evict entire groups of cache entries if the number of groups exceeds this value. > In WildFly, web sessions make use of grouping. A single web session will map to a single group of multiple cache entries, where the number of entries is not necessarily the same for a given session. In this case, evicting per cache entry does not make sense - all entries of a session should be evicted or not at all. Also, users can specify the max number of sessions they want to remain in memory. Until infinispan supports group-based eviction, translating this value to an appropriate max-entries is cumbersome and imprecise. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3761) Tests from org.infinispan.query.dsl.embedded package fail on all environmets

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3761?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3761: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2491 > Tests from org.infinispan.query.dsl.embedded package fail on all environmets > ---------------------------------------------------------------------------- > > Key: ISPN-3761 > URL: https://issues.jboss.org/browse/ISPN-3761 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Environment: OS: Windows 2012 64bit > Reporter: Jiří Holuša > Assignee: Mircea Markus > Attachments: log.txt > > > * Method throws assertion ERROR on Windows > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.createBeforeMethod > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > * These tests are failing periodically on Windows: > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testIteration3 > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testIteration4 > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testIteration5 > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testOrderByAsc > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testOrderByDesc > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testProjection1 > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testStartOffset > * This test failed only once out of three times: > ** org.infinispan.query.dsl.embedded.FilesystemQueryDslIterationTest.testMaxResults > * Test fails very often on RHEL > ** org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16 > here is trace log https://www.dropbox.com/s/yvrbs2i2tvh0wzz/ClusteredQueryDslConditionsTest... -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4172) Update to JCache 1.0 final

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4172?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4172: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Update to JCache 1.0 final > -------------------------- > > Key: ISPN-4172 > URL: https://issues.jboss.org/browse/ISPN-4172 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > JCache 1.0 has been released to Maven Central now. Update. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4157) Update JPA cache store XML parser to 7.0

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4157?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4157: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Update JPA cache store XML parser to 7.0 > ---------------------------------------- > > Key: ISPN-4157 > URL: https://issues.jboss.org/browse/ISPN-4157 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3 > > > Create a 7.0 XML parser for JPA cache store -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4158) Remove 6.0 XML parsers and related element/attributes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4158?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4158: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove 6.0 XML parsers and related element/attributes > ----------------------------------------------------- > > Key: ISPN-4158 > URL: https://issues.jboss.org/browse/ISPN-4158 > Project: Infinispan > Issue Type: Task > Components: Configuration > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3 > > > Remove 6.0 XML parsers and all related attributes/elements which are no longer used by 7.0 -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4172) Update to JCache 1.0 final

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4172?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4172: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2472, https://github.com/infinispan/infinispan/pull/2490 (was: https://github.com/infinispan/infinispan/pull/2472) > Update to JCache 1.0 final > -------------------------- > > Key: ISPN-4172 > URL: https://issues.jboss.org/browse/ISPN-4172 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > JCache 1.0 has been released to Maven Central now. Update. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4157) Update JPA cache store XML parser to 7.0

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4157?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4157: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2472, https://github.com/infinispan/infinispan/pull/2490 (was: https://github.com/infinispan/infinispan/pull/2472) > Update JPA cache store XML parser to 7.0 > ---------------------------------------- > > Key: ISPN-4157 > URL: https://issues.jboss.org/browse/ISPN-4157 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3 > > > Create a 7.0 XML parser for JPA cache store -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2014