April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3611) Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3611?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3611: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1078136|https://bugzilla.redhat.com/show_bug.cgi?id=1078136] from MODIFIED to ON_QA > Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch > ------------------------------------------------------------------------------------- > > Key: ISPN-3611 > URL: https://issues.jboss.org/browse/ISPN-3611 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: William Burns > Labels: 620 > Fix For: 6.0.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3952) Upgrade to Hibernate Search 4.5.0.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3952?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3952: ----------------------------------------------- Sanne Grinovero <sanne(a)redhat.com> changed the Status of [bug 1083737|https://bugzilla.redhat.com/show_bug.cgi?id=1083737] from NEW to ASSIGNED > Upgrade to Hibernate Search 4.5.0.Final > --------------------------------------- > > Key: ISPN-3952 > URL: https://issues.jboss.org/browse/ISPN-3952 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3934) Upgrade to Hibernate Search 4.5.0.CR1 and HQL-Parser 1.0.0.Alpha6

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3934?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3934: ----------------------------------------------- Sanne Grinovero <sanne(a)redhat.com> changed the Status of [bug 1083737|https://bugzilla.redhat.com/show_bug.cgi?id=1083737] from NEW to ASSIGNED > Upgrade to Hibernate Search 4.5.0.CR1 and HQL-Parser 1.0.0.Alpha6 > ----------------------------------------------------------------- > > Key: ISPN-3934 > URL: https://issues.jboss.org/browse/ISPN-3934 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Labels: 630 > Fix For: 7.0.0.Alpha1 > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3934) Upgrade to Hibernate Search 4.5.0.CR1 and HQL-Parser 1.0.0.Alpha6

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3934?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3934: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083737 > Upgrade to Hibernate Search 4.5.0.CR1 and HQL-Parser 1.0.0.Alpha6 > ----------------------------------------------------------------- > > Key: ISPN-3934 > URL: https://issues.jboss.org/browse/ISPN-3934 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Labels: 630 > Fix For: 7.0.0.Alpha1 > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3952) Upgrade to Hibernate Search 4.5.0.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3952?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3952: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083737 > Upgrade to Hibernate Search 4.5.0.Final > --------------------------------------- > > Key: ISPN-3952 > URL: https://issues.jboss.org/browse/ISPN-3952 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3979) JdbcStringBasedStore loading of Key2StringMapper class is too restrictive

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3979?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3979: ------------------------------- Fix Version/s: 7.0.0.Final > JdbcStringBasedStore loading of Key2StringMapper class is too restrictive > ------------------------------------------------------------------------- > > Key: ISPN-3979 > URL: https://issues.jboss.org/browse/ISPN-3979 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.1.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Final > > > Currently the Key2StringMapper of a JdbcStringBasedStore is specified to the JdbcStringBasedStoreConfigurationBuilder as a class name. Yes, there is a method that accepts a Class<? extends Key2StringMapper>, but that simply stores the getName() of the Class! The JdbcStringBasedStore loads the class using the class loader of the JdbcStringBasedStore class (via Class.forName(...). This is too restrictive. At the very least, JdbcStringBasedStore should use the classLoader defined in the cache Configuration (i.e. via ConfigurationBuilder.classLoader()) to load the class. Why not also allow the JdbcStringBasedStoreConfigurationBuilder to specify a Key2StringMapper instance? > I would really like to make use of Key2StringMapper in WildFly to allow users the option to persist web sessions and SFSBs via the JdbcStringBasedStore (instead of the binary bucket-based store), but the current mechanism is incompatible with use cases where the Key2StringMapper is not known to class loader of the infinispan module. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2916) Group-based expiration

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-2916: ------------------------------------ Indeed [~pferraro], that was the solution I was going to suggest as well. OTOH Radim is also right, there are two problems: 1. Expiration doesn't actually remove the entry, so it's possible for an entry to re-appear in the cache if the timer is not monotonic. In particular, it's very likely that the key does not expire at the exact same time on all the nodes, so a node that doesn't have the group locally may get different results depending on which owner answers first (since we send the remote get to all the owners). True, this won't happen very often, but it can certainly happen during state transfer. 2. Reading doesn't acquire any locks. So just because you read the a key in a transaction, it doesn't mean that the key can't expire while the transaction is active. Note that expiration doesn't acquire any locks either, but that might need to change in order to implement expiration listeners. > Group-based expiration > ---------------------- > > Key: ISPN-2916 > URL: https://issues.jboss.org/browse/ISPN-2916 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.2.5.Final > Reporter: Paul Ferraro > Assignee: Mircea Markus > > Now that WildFly represents a web session as a group of cache entries (instead of a single entry containing an atomic map), there are a few hurdles preventing us from leveraging infinispan-managed expiration. > One of which is the fact that expiration of cache entries within a group *must* be atomic. It would be very bad if a request arrives for a session whose entries are in the process of being expired. The expiration thread should obtain a lock on *all* the keys for a group (or at least some pre-determined "primary" key), so that late session access doesn't result in session attributes mysteriously disappearing (because they were independently expired). This can also cause integrity constraint violations if cache entries reference other entries in the group. e.g. currently the "primary" cache entry for a session (keyed by session id), contains a set of attribute names. These names correspond to other cache entries that contain the value of a given attribute for that session. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4171) Allow Infinispan to properly use a foreign channel

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4171?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-4171: ------------------------------- Description: Currently, Infinispan assumes full ownership of a provided channel. It registers the up handler of the CommandAwareDispatcherFactory with the channel. If there is already a registered up handler, it gets overwritten. Currently, WildFly shares Infinispan's channel for use by other services - however, it needs to bend over backwards to make sure infinispan is initialized before attempting to fork/mux it. If an Infinispan cache manager is built with a channel that is used by some other service, it should instead fork that channel using ForkChannel. This let's us do something like, say, let WF and Infinispan share a channel without requiring infinispan to start first, or to use the same channel for multiple cache managers. was: Currently, Infinispan assumes full ownership of a provided channel. It registers the up handler of the CommandAwareDispatcherFactory with the channel. If there is already a registered up handler, it gets overwritten. Currently, WildFly shares Infinispan's channel for use by other services - however, it needs to bend over backwards to make sure infinispan is initialized before attempting to fork/mux it. If an Infinispan cache manager is built with a channel that is used by some other service, it should instead fork that channel using ForkChannel. This let's us do something like, say, let WF and Infinispan share a channel without requiring infinispan to start first, or use the same channel for multiple cache managers. > Allow Infinispan to properly use a foreign channel > -------------------------------------------------- > > Key: ISPN-4171 > URL: https://issues.jboss.org/browse/ISPN-4171 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.0.0.Alpha2 > Reporter: Paul Ferraro > Assignee: Dan Berindei > > Currently, Infinispan assumes full ownership of a provided channel. It registers the up handler of the CommandAwareDispatcherFactory with the channel. If there is already a registered up handler, it gets overwritten. > Currently, WildFly shares Infinispan's channel for use by other services - however, it needs to bend over backwards to make sure infinispan is initialized before attempting to fork/mux it. > If an Infinispan cache manager is built with a channel that is used by some other service, it should instead fork that channel using ForkChannel. This let's us do something like, say, let WF and Infinispan share a channel without requiring infinispan to start first, or to use the same channel for multiple cache managers. -- 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

11 years, 6 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3920: ----------------------------------------------- Ion Savin <isavin(a)redhat.com> changed the Status of [bug 1083635|https://bugzilla.redhat.com/show_bug.cgi?id=1083635] from NEW to POST > 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3611) Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3611?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3611: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 1078136|https://bugzilla.redhat.com/show_bug.cgi?id=1078136] from ASSIGNED to MODIFIED > Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch > ------------------------------------------------------------------------------------- > > Key: ISPN-3611 > URL: https://issues.jboss.org/browse/ISPN-3611 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: William Burns > Labels: 620 > Fix For: 6.0.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2014