October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4857) Extend old value/metadata information to Hot Rod remote events

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4857: -------------------------------------- Summary: Extend old value/metadata information to Hot Rod remote events Key: ISPN-4857 URL: https://issues.jboss.org/browse/ISPN-4857 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.CR2, 7.0.0.Final Clustered listeners now provide old value and old metadata in their filter/converter callbacks, which can be useful for server-side filter/converter instances used in Hot Rod remote events. Investigate whether any code changes required in Hot Rod client/server code to take advantage of this. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4853) OSGI metadata import-package version ranges are too narrow

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4853?page=com.atlassian.jira.plugin.... ] Ion Savin commented on ISPN-4853: --------------------------------- Regarding the blueprint package Section "121.13.5 Type Compatibility" from the OSGi Service Compendium suggests blueprint bundles should import it: "To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package." > OSGI metadata import-package version ranges are too narrow > ---------------------------------------------------------- > > Key: ISPN-4853 > URL: https://issues.jboss.org/browse/ISPN-4853 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR1 > Environment: Any OSGI environment (but found on Glassfish / Apache Felix). > Reporter: Andrew Scully > Labels: OSGI, bundle, import, package > > The OSGI import-package statement is specifying specific dependencies on a number of packages, rather than a range. This makes it impossible to install Infinispan 7 in any OSGI environment that doesn't have the exact versions of the dependencies present. > Normally, the version range for dependencies would range from the major:minor:revision of the minimum requirement, up to the next major version (exclusive). > I've copied and pasted the "Imported Packages" output below from my Apache Felix bundle console for the infinispan-core bundle. > The bundle will not resolve because the versions of javax.transaction, JGroups, jboss-marshalling and jboss-logging are slightly newer than those required. > The org.osgi.service.blueprint dependency is also dubious -- I'm not sure you usually have a runtime dependency on this package (even if you use Blueprint). > For example, the following statement... > org.jboss.marshalling;version="[1.4.4.Final,1.4.4.Final]" > ...should probably be... > org.jboss.marshalling;version="[1.4.4.Final,2)" > ...in order to comply with standard semantic versioning policy. > Felix output: > javax.management from org.apache.felix.framework (0) > javax.naming from org.apache.felix.framework (0) > javax.security.auth from org.apache.felix.framework (0) > javax.transaction,version=[1.1.0,1.1.0] -- Cannot be resolved > javax.transaction.xa,version=[1.1.0,1.1.0] -- Cannot be resolved > javax.xml.namespace from org.apache.felix.framework (0) > javax.xml.parsers from org.apache.felix.framework (0) > javax.xml.stream from org.apache.felix.framework (0) > javax.xml.transform from org.apache.felix.framework (0) > javax.xml.transform.dom from org.apache.felix.framework (0) > javax.xml.transform.stream from org.apache.felix.framework (0) > net.jcip.annotations from com.springsource.net.jcip.annotations (62) > org.infinispan.commons,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.api,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.configuration,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.equivalence,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.executors,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.hash,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.io,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.logging,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.marshall,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.marshall.jboss,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.util,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.util.concurrent,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.infinispan.commons.util.concurrent.jdk8backported,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159) > org.jboss.logging,version=[3.1.2.GA,3.1.2.GA] -- Cannot be resolved > org.jboss.marshalling,version=[1.4.4.Final,1.4.4.Final] -- Cannot be resolved > org.jboss.marshalling.util,version=[1.4.4.Final,1.4.4.Final] -- Cannot be resolved > org.jgroups,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.blocks,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.blocks.mux,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.jmx,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.logging,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.protocols,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.protocols.relay,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.protocols.tom,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.stack,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.jgroups.util,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved > org.osgi.service.blueprint,version=[1.0.0,2.0.0) -- Cannot be resolved > org.w3c.dom from org.apache.felix.framework (0) > org.xml.sax from org.apache.felix.framework (0) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4856) PartitionHandling: majority check in PreferConsistencyStrategy is incorrect

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4856: ---------------------------------- Summary: PartitionHandling: majority check in PreferConsistencyStrategy is incorrect Key: ISPN-4856 URL: https://issues.jboss.org/browse/ISPN-4856 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.CR2 If the cluster has 3 members and one of them crashes, the remaining 2 should stay available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4852) PartitionHandling: support replicated caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4852?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4852: ------------------------------- Status: Open (was: New) > PartitionHandling: support replicated caches > -------------------------------------------- > > Key: ISPN-4852 > URL: https://issues.jboss.org/browse/ISPN-4852 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > ISPN-4574 already did most of the job, but the PartitionHandlingManager component wasn't created for replicated caches. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4852) PartitionHandling: support replicated caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4852?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4852: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2964 > PartitionHandling: support replicated caches > -------------------------------------------- > > Key: ISPN-4852 > URL: https://issues.jboss.org/browse/ISPN-4852 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > ISPN-4574 already did most of the job, but the PartitionHandlingManager component wasn't created for replicated caches. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4828) Increasing default internal thread pool size

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4828?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4828: ------------------------------- Status: Open (was: New) > Increasing default internal thread pool size > -------------------------------------------- > > Key: ISPN-4828 > URL: https://issues.jboss.org/browse/ISPN-4828 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 7.0.0.CR1 > Reporter: Matej Čimbora > Assignee: Dan Berindei > Priority: Critical > > Using synchronous replication with high number of concurrent clients doing put() operations over a shared set of keys, lock-acquisition timeouts occur when various thread pools (internal, jgroups oob) do not have appropriate size. > org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [3 seconds] on key [key_00000000000003B4] for requestor [Thread[OOB-66,default,node03-12795,5,main]]! Lock held by [Thread[OOB-314,default,node03-12795,5,main]] > [org.infinispan.interceptors.InvocationContextInterceptor] (Stressor-1) ISPN000136: Execution error > org.infinispan.util.concurrent.TimeoutException: org.infinispan.util.concurrent.TimeoutException: Node node04-24454 timed out > This applies to both transactional and non-transactional configuration. The problem can be mitigated by increasing Infinispan's internal thread pool size (defined for remoteCommandsExecutor, blockingBoundedQueueThreadPool). In order to improve user experience either: > a) When needed, the size of the thread pool should be increased as the load increases > b) The default values should be high enough to handle even significant load (in terms of number of concurrent clients per node) > c) The documentation should describe how the end user should size the thread pools based on expected load on the system -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4828) Increasing default internal thread pool size

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4828?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-4828: ---------------------------------- Assignee: Dan Berindei > Increasing default internal thread pool size > -------------------------------------------- > > Key: ISPN-4828 > URL: https://issues.jboss.org/browse/ISPN-4828 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 7.0.0.CR1 > Reporter: Matej Čimbora > Assignee: Dan Berindei > Priority: Critical > > Using synchronous replication with high number of concurrent clients doing put() operations over a shared set of keys, lock-acquisition timeouts occur when various thread pools (internal, jgroups oob) do not have appropriate size. > org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [3 seconds] on key [key_00000000000003B4] for requestor [Thread[OOB-66,default,node03-12795,5,main]]! Lock held by [Thread[OOB-314,default,node03-12795,5,main]] > [org.infinispan.interceptors.InvocationContextInterceptor] (Stressor-1) ISPN000136: Execution error > org.infinispan.util.concurrent.TimeoutException: org.infinispan.util.concurrent.TimeoutException: Node node04-24454 timed out > This applies to both transactional and non-transactional configuration. The problem can be mitigated by increasing Infinispan's internal thread pool size (defined for remoteCommandsExecutor, blockingBoundedQueueThreadPool). In order to improve user experience either: > a) When needed, the size of the thread pool should be increased as the load increases > b) The default values should be high enough to handle even significant load (in terms of number of concurrent clients per node) > c) The documentation should describe how the end user should size the thread pools based on expected load on the system -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4851) Make SyncConsistentHashFactory the default CH factory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4851?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-4851: ---------------------------------- Assignee: Dan Berindei > Make SyncConsistentHashFactory the default CH factory > ----------------------------------------------------- > > Key: ISPN-4851 > URL: https://issues.jboss.org/browse/ISPN-4851 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Core > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.CR2, 7.0.0.Final > > > With ISPN-4682 fixed, SyncConsistentHashFactory should be good enough to be the default. It still allows for more variation in the number of owned segments per node (+/-10% owned segments and +/-20% for primary-owned segments), but that should be acceptable for most purposes. > The major advantage of SCHF is that it depends only on the cache members and not on the order they joined. Users expect a key to map to the same node in all caches (as long as the caches have the same members). > One downside of SCHF, especially for testing, is that the segment ownership differs between test runs (being based on the random address assigned to each node). However, most tests that depend on key ownership should use {{ControlledConsistentHashFactory}} anyway. > We also need to verify that the number of segments moved by SCHF is comparable to the number of segments moved by DefaultConsistentHashFactory (ISPN-3729). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4624) Allow custom partition handling strategy

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4624?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4624: ------------------------------------ The RebalancePolicy was already merged with the PartitionHandlingStrategy and the new interface is AvailabilityStrategy. There is a corner case for get commands where we assume that we will receive an availability mode update soon (ISPN-4673). That decision should be moved to the availability strategy. > Allow custom partition handling strategy > ---------------------------------------- > > Key: ISPN-4624 > URL: https://issues.jboss.org/browse/ISPN-4624 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Dan Berindei > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > Users should be able to configure a custom PartitionHandlingStrategy. It should be able to specify a behaviour on merge as well. > We might want to merge this with the RebalancePolicy, which was also supposed to be configurable. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4673) Split-brain: get() returns null when all owners are removed from view

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4673?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4673: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2964 > Split-brain: get() returns null when all owners are removed from view > --------------------------------------------------------------------- > > Key: ISPN-4673 > URL: https://issues.jboss.org/browse/ISPN-4673 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: partition_handling > Fix For: 7.0.0.CR2 > > > After split brain: when calling {{cache.get()}} for an entry that has all owners in the missing partition, JGroupsTransport removes the target nodes that are no longer members and then returns empty response map > BaseDistributionInterceptor.invokeClusterGetCommandRemotely takes empty map as null response, although the entry is just not available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 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 October 2014