April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5410) Stronger isolation between modules needing Infinispan Core and those needing Lucene

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5410?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-5410: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3420 > Stronger isolation between modules needing Infinispan Core and those needing Lucene > ----------------------------------------------------------------------------------- > > Key: ISPN-5410 > URL: https://issues.jboss.org/browse/ISPN-5410 > Project: Infinispan > Issue Type: Enhancement > Components: Build process > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.2.0.Final > > > The WildFly module 'org.infinispan:main' is exporting Infinispan Query as a convenience for users, but this in turn exposes Hibernate Search and Apache Lucene, which are often not desirable, especially to other internal modules which simply need access to the primary Infinispan integration contracts. > I will propose a split of the modules which maintains the convenience for end users but avoids bloated classloaders. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5410) Stronger isolation between modules needing Infinispan Core and those needing Lucene

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-5410: ------------------------------------- Summary: Stronger isolation between modules needing Infinispan Core and those needing Lucene Key: ISPN-5410 URL: https://issues.jboss.org/browse/ISPN-5410 Project: Infinispan Issue Type: Enhancement Components: Build process Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 7.2.0.Final The WildFly module 'org.infinispan:main' is exporting Infinispan Query as a convenience for users, but this in turn exposes Hibernate Search and Apache Lucene, which are often not desirable, especially to other internal modules which simply need access to the primary Infinispan integration contracts. I will propose a split of the modules which maintains the convenience for end users but avoids bloated classloaders. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3691) Make client side Connection refused error TRACE

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3691?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-3691. ------------------------------------ Fix Version/s: 7.0.0.Final (was: 7.2.0.Final) Resolution: Duplicate Issue Already fixed via ISPN-4082 > Make client side Connection refused error TRACE > ----------------------------------------------- > > Key: ISPN-3691 > URL: https://issues.jboss.org/browse/ISPN-3691 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.0.CR1, 6.0.0.Final > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 7.0.0.Final > > > After solving ISPN-3454, it seems that only remaining client-side error during node crashes is "Connection refused": > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE... > This has been reported before as ISPN-1794 or ISPN-1119, but actually it seems like it reappeared in different place. > Sorry for not reporting sooner, I got used to ignoring some of the long-open cosmetic low-prio log message issues, that I forgot about this one... > The issue here is that these "Connection refused" problems are retry-able, so the client log shouldn't contain error. > Maybe only some info level message about failing over to different node. But that's actually already reported by the INFO level messages about the topology changes -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5174) Transaction cannot be recommitted after ownership changes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5174?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5174: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1202341|https://bugzilla.redhat.com/show_bug.cgi?id=1202341] from ON_QA to VERIFIED > Transaction cannot be recommitted after ownership changes > --------------------------------------------------------- > > Key: ISPN-5174 > URL: https://issues.jboss.org/browse/ISPN-5174 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.CR2, 7.1.1.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Beta2, 7.2.0.Final > > > Once transaction is completed, it cannot commit again. If it should commit more keys since it has become an owner of some new keys modified in this transaction, it just ignores the further commit. > There is a race with state transfer which can bring an old value (with StateResponseCommand sent before it is commited) but the value is not set by the ongoing transaction either. > This results with stale value stored on one node. > In my case, The problematic part is transaction <edg-perf01-62141>:15066 (consisting of 10 modifications) which got prepared and committed on edg-perf04 in topology 25. Before the originator finishes, topology changes and 04 requests ongoing transactions: > {code} > 11:06:11,369 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (transport-thread-17) Replication task sending StateRequestCommand{cache=testCache, origin=edg-perf04-35097, type=GET_TRANSACTIONS, topologyId=28, segments=[275, 1, 278, 9, 282, 286, 17, 259, 25, 267, 171, 169, 33, 306, 175, 173, 310, 172, 314, 41, 167, 165, 318, 187, 290, 49, 185, 191, 294, 189, 179, 298, 57, 177, 183, 302, 181, 343, 205, 201, 338, 203, 336, 351, 197, 349, 199, 347, 193, 345, 195, 326, 85, 87, 322, 93, 332, 95, 330, 89, 91, 103, 101, 99, 506, 97, 105, 357, 359, 353, 355, 361]} to single recipient edg-perf01-62141 with response mode GET_ALL > 11:06:11,495 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread-17) Applying 6 transactions for cache testCache transferred from node edg-perf01-62141 > {code} > However I don't see how these are applied, since PrepareCommand is not created again - from the code I see only that backup locks are added. Not sure if the transaction is registered at all, since it was already completed on this node (but at that time it did not own key_00000000000002EB). > After originator stores the entry, it sends one more CommitCommand with topology 28: > {code} > 11:06:11,619 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-2) Replication task sending CommitCommand {gtx=GlobalTransaction:<edg-perf01-62141>:15066:local, cacheName='testCache', topologyId=28} to addresses [edg-perf03-20530, edg-perf04-35097] with response mode GET_ALL > {code} > 04 receives several CommitCommands (both from originator and forwards), but all of them are ignored as the transaction is completed. > I don't see the logs where state transfer is assembled, but it's probably before the entry is stored on originator as the state transfer contains the old entry: > {code} > 11:06:13,449 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-91) Received chunk with keys [key_000000000000065B, key_00000000000006BE, key_FFFFFFFFFFFFE62F, key_0000000000001F42, key_000000000000027B, key_000000000000159D, key_00000000000002EB, key_00000000000002BB] for segment 343 of cache testCache from node edg-perf01-62141 > 11:06:13,454 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-91) Store ImmortalCacheEntry{key=key_00000000000002EB, value=[2 #7: 366, 544, 576, 804, 1061, 1181, 1290, ]} in container > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3949) Support querying on simple values

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3949?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3949: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1215741 > Support querying on simple values > --------------------------------- > > Key: ISPN-3949 > URL: https://issues.jboss.org/browse/ISPN-3949 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Sanne Grinovero > Labels: 64QueryBlockers > > Ironically while we support searching on rich domain objects, we don't allow running queries on the most simple types which users could store in the grid: Strings, Numbers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5192) infinispan-remote uber jar contains 2x versions of shaded javassist packages

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5192?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5192: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > infinispan-remote uber jar contains 2x versions of shaded javassist packages > ----------------------------------------------------------------------------- > > Key: ISPN-5192 > URL: https://issues.jboss.org/browse/ISPN-5192 > Project: Infinispan > Issue Type: Bug > Components: Build process, Remote Protocols > Affects Versions: 7.1.0.CR2 > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > > Both the shaded protostream library and the infinispan-remote uberjar package javassist. The latter should be removed. The package should be relocated to avoid conflict with containers which expose the library (i.e. weblogic) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5268) Backup segments may not be removed after failed state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5268?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5268: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1199210|https://bugzilla.redhat.com/show_bug.cgi?id=1199210] from ASSIGNED to ON_QA > Backup segments may not be removed after failed state transfer > --------------------------------------------------------------- > > Key: ISPN-5268 > URL: https://issues.jboss.org/browse/ISPN-5268 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Dist cache can lost data if the primary and all backups are lost at the same time. To detect such data loss, they are monitoring the tatal sum of entries from all nodes using JMX. If the sum reduces by a considerable ammount, data loss (by lost a segment) is concluded. But they found a case that the sum increases, not decreases, after failed state transfer. This is probably caused by an extra backup segment that hasn't been cleaned up when the last state transfer failed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5406) Deprecate eviction thread pool executor in favor of expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5406?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5406: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3414 > Deprecate eviction thread pool executor in favor of expiration > -------------------------------------------------------------- > > Key: ISPN-5406 > URL: https://issues.jboss.org/browse/ISPN-5406 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.0.CR1 > Reporter: William Burns > Fix For: 7.2.0.Final > > > We currently have a "eviction thread pool" however this thread pool is only ever used for expiration of the data container and the various cache stores. We should deprecate any references of eviction and replace with appropriate expiration naming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5406) Deprecate eviction thread pool executor in favor of expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5406?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-5406: ----------------------------------- Assignee: William Burns > Deprecate eviction thread pool executor in favor of expiration > -------------------------------------------------------------- > > Key: ISPN-5406 > URL: https://issues.jboss.org/browse/ISPN-5406 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.2.0.Final > > > We currently have a "eviction thread pool" however this thread pool is only ever used for expiration of the data container and the various cache stores. We should deprecate any references of eviction and replace with appropriate expiration naming. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5265) Optimize Getall operations over Hot Rod

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5265?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5265: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.2.0.Final Resolution: Done > Optimize Getall operations over Hot Rod > --------------------------------------- > > Key: ISPN-5265 > URL: https://issues.jboss.org/browse/ISPN-5265 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > Fix For: 7.2.0.Final > > > - GetAll operation: to ensure that there’s a way to batch get multiple objects together. > - Improve performance for large data sets. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015