March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4169) After generic loader child setup -- server fails start (AdvancedCacheLoader needed)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4169?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4169: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1081524|https://bugzilla.redhat.com/show_bug.cgi?id=1081524] from NEW to CLOSED > After generic loader child setup -- server fails start (AdvancedCacheLoader needed) > ----------------------------------------------------------------------------------- > > Key: ISPN-4169 > URL: https://issues.jboss.org/browse/ISPN-4169 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: William Burns > Attachments: 621CR2genericLoaderCannotPreload > > > From JON point of view we are able to set up generic loader cache child resource. > However, the server itself experience obstacles to start successfully. > See the attached log please with the full stack traces. -- 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)

Galder Zamarreño created ISPN-4172: -------------------------------------- Summary: 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-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 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, WF shares the same channel used by infinispan for other things - 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 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

12 years

1
0
0 / 0

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

by Paul Ferraro (JIRA)

Paul Ferraro created ISPN-4171: ---------------------------------- Summary: 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, WF shares the same channel used by infinispan for other things - 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. -- 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-694) Create expiration notification for in-memory cache entries

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-694?page=com.atlassian.jira.plugin.s... ] William Burns commented on ISPN-694: ------------------------------------ I don't see any issue. The problem though is that we will need to have the notification say which node it expired on probably. This way you have it occur multiple times. Although personally using a distributed cache with max idle is just inherently broken, since depending on which node responds first you could find the value or not. > Create expiration notification for in-memory cache entries > ---------------------------------------------------------- > > Key: ISPN-694 > URL: https://issues.jboss.org/browse/ISPN-694 > Project: Infinispan > Issue Type: Feature Request > Components: Eviction > Environment: any > Reporter: Edouard Boily > Assignee: Galder Zamarreño > Attachments: 01.patch > > > Create a CacheEntryExpired notification and make EvictionManager send this notification when a cache entry is evicted because it is expired. > Also mage sure the cache entry value is sent over in the event. > CacheEntryEvicted notification should also send the entry value in the event. -- 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-3514) Revamp embedded Infinispan configuration

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3514?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3514: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Revamp embedded Infinispan configuration > ----------------------------------------- > > Key: ISPN-3514 > URL: https://issues.jboss.org/browse/ISPN-3514 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Server > Reporter: Mircea Markus > Assignee: Galder Zamarreño > Labels: roadmap > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > Umbrella JIRA for all the configurations-related Infinispan enhancements. -- 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-4170) Upgrade to JGroups 3.5.0.Beta2

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4170: ---------------------------------- Summary: Upgrade to JGroups 3.5.0.Beta2 Key: ISPN-4170 URL: https://issues.jboss.org/browse/ISPN-4170 Project: Infinispan Issue Type: Component Upgrade Components: Core Affects Versions: 7.0.0.Alpha2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Alpha3 {quote} Released. Major new feature compared to Beta1: - Messages are now always looped back (mcasts are discarded when copies are received) https://issues.jboss.org/browse/JGRP-1765 - DONT_LOOPBACK flag: mesages can now be dropped at the transport level https://issues.jboss.org/browse/JGRP-1816 - Removed bottleneck when sending a message to a non-existent dest https://issues.jboss.org/browse/JGRP-1815 - UNICAST3: connections to non-members are now closed more quickly https://issues.jboss.org/browse/JGRP-1814 - SHARED_LOOPBACK_PING: new discovery protocol which always discovers members in the same JVM. Used by unit tests. https://issues.jboss.org/browse/JGRP-1809 - Hardened code for generating seqnos in UNICAST3 and NAKACK2 https://issues.jboss.org/browse/JGRP-1807 {quote} -- 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-3529) Add support for the segment-based CH in the HotRod protocol

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3529?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3529: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add support for the segment-based CH in the HotRod protocol > ----------------------------------------------------------- > > Key: ISPN-3529 > URL: https://issues.jboss.org/browse/ISPN-3529 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > The server CH changed in version 5.2 from virtual-nodes-based to segment-based, but the client CH stayed the same. The server is able to translate the server CH into a client CH, but the translation is imperfect: > 1. Sometimes the client CH computes a different primary owner than the server CH. > 2. The client CH gets slower as the number of segments increases, the server CH performance stays the same. -- 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-833) Revisit cache name predefinition limitation for cache servers

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-833?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ISPN-833: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Revisit cache name predefinition limitation for cache servers > ------------------------------------------------------------- > > Key: ISPN-833 > URL: https://issues.jboss.org/browse/ISPN-833 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches: > 1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days. > 2. Infinispan has issues dealing with asymmetric clusters (ISPN-658). > Once these two issues have been resolved, revisit the limitation. -- 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 commented on ISPN-4157: ---------------------------------------- Make sure JpaConfigurationTest is reenabled. > 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 March 2014