May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5434) ClusteringConfigurationBuilder.l1() javadoc incorrectly states that the l1 method enables l1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5434?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5434: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.0.Final Resolution: Done > ClusteringConfigurationBuilder.l1() javadoc incorrectly states that the l1 method enables l1 > -------------------------------------------------------------------------------------------- > > Key: ISPN-5434 > URL: https://issues.jboss.org/browse/ISPN-5434 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.10.Final, 7.1.1.Final > Reporter: Dominik Pospisil > Assignee: William Burns > Fix For: 7.2.2.Final, 8.0.0.Alpha1, 8.0.0.Final > > > ClusteringConfigurationBuilder.l1() method javadocs says: > This method allows configuration of the L1 cache for distributed caches. When this method is called, it automatically enables L1. > However what it does is it just return plain instance of L1ConfigurationBuilder created by empty constructor whith default (disabled) value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5386) Tx succeeds on coord, while being rollbacked on other participants due to Tx pruning

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5386?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5386: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1212795|https://bugzilla.redhat.com/show_bug.cgi?id=1212795] from ASSIGNED to POST > Tx succeeds on coord, while being rollbacked on other participants due to Tx pruning > ------------------------------------------------------------------------------------ > > Key: ISPN-5386 > URL: https://issues.jboss.org/browse/ISPN-5386 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Matej Čimbora > Assignee: Dan Berindei > Fix For: 7.2.0.Final > > > All participants of transaction share the same topology. TX gets successfully prepared & commited on coordinator. > {code} > 03:49:27,759 DEBUG [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,edg-perf08-48196) New view accepted: [edg-perf08-48196|18] (5) [edg-perf08-48196, edg-perf01-23632, edg-perf02-34805, edg-perf03-16232, edg-perf04-41106] > 03:49:41,051 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (transport-thread-9) Installing new cache topology CacheTopology{id=53, rebalanceId=19, currentCH=DefaultConsistentHash{ns = 512, owners = (5)[edg-perf08-48196: 103+101, edg-perf01-23632: 102+103, edg-perf02-34805: 102+103, edg-perf03-16232: 102+103, edg-perf04-41106: 103+102]}, pendingCH=null, unionCH=null, actualMembers=[edg-perf08-48196, edg-perf01-23632, edg-perf02-34805, edg-perf03-16232, edg-perf04-41106]} on cache testCache > ... > 03:51:34,005 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-1) edg-perf08-48196 invoking PrepareCommand { ... gtx=GlobalTransaction:<edg-perf08-48196>:13330:local, cacheName='testCache', topologyId=53} to recipient list [edg-perf03-16232, edg-perf08-48196, edg-perf02-34805, edg-perf04-41106, edg-perf01-23632] > 03:51:36,329 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-1) Responses: [sender=edg-perf03-16232,received=true, suspected=false] [sender=edg-perf02-34805, received=true, suspected=false] [sender=edg-perf04-41106, received=true, suspected=false] [sender=edg-perf01-23632, received=true, suspected=false] > 03:51:36,342 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-1) edg-perf08-48196 invoking CommitCommand {gtx=GlobalTransaction:<edg-perf08-48196>:13330:local, cacheName='testCache', topologyId=53} to recipient list [edg-perf03-16232, edg-perf08-48196, edg-perf02-34805, edg-perf04-41106, edg-perf01-23632] with options RpcOptions{timeout=60000, unit=MILLISECONDS, fifoOrder=false, totalOrder=false, responseFilter=null, responseMode=SYNCHRONOUS_IGNORE_LEAVERS, skipReplicationQueue=false} > 03:51:36,703 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-1) Responses: [sender=edg-perf03-16232, retval=SuccessfulResponse{responseValue=null} , received=true, suspected=false] [sender=edg-perf02-34805, retval=SuccessfulResponse{responseValue=null} , received=true, suspected=false] [sender=edg-perf04-41106, retval=SuccessfulResponse{responseValue=null} , received=true, suspected=false] [sender=edg-perf01-23632, retval=SuccessfulResponse{responseValue=null} , received=true, suspected=false] > {code} > The problem is, that other participating nodes rollback it, as TX with higher id was completed before. Successfull response is returned for both prepare & commit commands. > {code} > 03:49:58,190 TRACE [org.infinispan.transaction.TransactionTable] (remote-thread-499) Marking transaction GlobalTransaction:<edg-perf08-48196>:13337:local as completed > ... > 03:51:34,122 TRACE [org.infinispan.transaction.TransactionTable] (remote-thread-593) Created and registered remote transaction RemoteTransaction{ ... lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, lookedUpEntriesTopology=2147483647, isMarkedForRollback=false, tx=GlobalTransaction:<edg-perf08-48196>:13330:remote, state=null} > 03:51:34,073 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-593) Calling perform() on PrepareCommand { ... gtx=GlobalTransaction:<edg-perf08-48196>:13330:remote, cacheName='testCache', topologyId=53} > 03:51:34,342 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-593) Rolling back remote transaction GlobalTransaction:<edg-perf08-48196>:13330:remote because either already completed (true) or originator no longer in the cluster (false). > 03:51:34,639 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-593) About to send back response null for command PrepareCommand { ... gtx=GlobalTransaction:<edg-perf08-48196>:13330:remote, cacheName='testCache', topologyId=53} > 03:51:36,355 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-589) Calling perform() on CommitCommand {gtx=GlobalTransaction:<edg-perf08-48196>:13330:remote, cacheName='testCache', topologyId=53} > 03:51:36,355 TRACE [org.infinispan.commands.tx.AbstractTransactionBoundaryCommand] (remote-thread-589) Did not find a RemoteTransaction for GlobalTransaction:<edg-perf08-48196>:13330:remote > 03:51:36,355 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-589) About to send back response SuccessfulResponse{responseValue=null} for command CommitCommand {gtx=GlobalTransaction:<edg-perf08-48196>:13330:remote, cacheName='testCache', topologyId=53} > {code} > Exception response should be returned instead to avoid incorrect assumptions about presence of updated entry in the cache. > [~dan.berindei] spotted lastPrunedTxId modifications are not logged, let's make sure they are. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4955) JCache implementation over HotRod

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4955?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-4955: --------------------------------------- Assignee: Gustavo Fernandes (was: Ion Savin) > JCache implementation over HotRod > --------------------------------- > > Key: ISPN-4955 > URL: https://issues.jboss.org/browse/ISPN-4955 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Tristan Tarrant > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-5298: --------------------------------------- Assignee: Gustavo Fernandes > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > Assignee: Gustavo Fernandes > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5298: ------------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3313, https://github.com/infinispan/infinispan/pull/3452 (was: https://github.com/infinispan/infinispan/pull/3313) > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2145) No descriptions for invalid jgroups configuration files

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2145?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2145: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3451 > No descriptions for invalid jgroups configuration files > ------------------------------------------------------- > > Key: ISPN-2145 > URL: https://issues.jboss.org/browse/ISPN-2145 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.2.FINAL, 7.0.0.CR1 > Environment: Any > Reporter: Dmitry Udalov > Assignee: Tristan Tarrant > Fix For: 7.2.2.Final, 8.0.0.Final > > > Can't find error's description for invalid jgroups configuration files. Shuffling elements of the file (why not!) makes it invalid, but log-files only report the existence of the error and you have to debug it to figure out the problem. It would be easier if the class JGroupsTransport also reports the exception, not just a generic message in blocks like > } catch (Exception e) { > log.errorCreatingChannelFromConfigFile(cfg); > throw new CacheException(e); > } > As a result log-file contains a lot of generic messages without explaining the problem, which in my case was quite helpful: > java.lang.Exception: events [GET_DIGEST SET_DIGEST FIND_INITIAL_MBRS FIND_ALL_VIEWS ] are required by GMS, but not provided by any of the protocols below it -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2145) No descriptions for invalid jgroups configuration files

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2145?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2145: ---------------------------------- Fix Version/s: 7.2.2.Final > No descriptions for invalid jgroups configuration files > ------------------------------------------------------- > > Key: ISPN-2145 > URL: https://issues.jboss.org/browse/ISPN-2145 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.2.FINAL, 7.0.0.CR1 > Environment: Any > Reporter: Dmitry Udalov > Assignee: Tristan Tarrant > Fix For: 7.2.2.Final, 8.0.0.Final > > > Can't find error's description for invalid jgroups configuration files. Shuffling elements of the file (why not!) makes it invalid, but log-files only report the existence of the error and you have to debug it to figure out the problem. It would be easier if the class JGroupsTransport also reports the exception, not just a generic message in blocks like > } catch (Exception e) { > log.errorCreatingChannelFromConfigFile(cfg); > throw new CacheException(e); > } > As a result log-file contains a lot of generic messages without explaining the problem, which in my case was quite helpful: > java.lang.Exception: events [GET_DIGEST SET_DIGEST FIND_INITIAL_MBRS FIND_ALL_VIEWS ] are required by GMS, but not provided by any of the protocols below it -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4504: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1220328|https://bugzilla.redhat.com/show_bug.cgi?id=1220328] from ASSIGNED to POST > Topology id is not properly set on ClusteredGetCommands > ------------------------------------------------------- > > Key: ISPN-4504 > URL: https://issues.jboss.org/browse/ISPN-4504 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target. > I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7:: > | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) | > | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply | > | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply | -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4198) Commands sent by another node before the local node joined are not ignored properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4198: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1220328|https://bugzilla.redhat.com/show_bug.cgi?id=1220328] from ASSIGNED to POST > Commands sent by another node before the local node joined are not ignored properly > ----------------------------------------------------------------------------------- > > Key: ISPN-4198 > URL: https://issues.jboss.org/browse/ISPN-4198 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: 630, testsuite_stability > Fix For: 7.0.0.Alpha3 > > > This is related to ISPN-3731. Commands that were sent by another node before the local node joined were supposed to be ignored in {{InboundInvocationHandler}}. > But the ISPN-3731 fix was incomplete, and old commands are still executed on the joiner - although the response is sent to the originator before the command is executed. > I believe this was causing random failures in ReplCommandForwardingTest. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4503) Commands with topology id 0 are not properly ignored on joiners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4503?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4503: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1220328|https://bugzilla.redhat.com/show_bug.cgi?id=1220328] from ASSIGNED to POST > Commands with topology id 0 are not properly ignored on joiners > --------------------------------------------------------------- > > Key: ISPN-4503 > URL: https://issues.jboss.org/browse/ISPN-4503 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > InboundInvocationHandlerImpl is supposed to ignore commands sent with a topology id smaller than the first topology id in which the local node was a member. But there is a loophole when the command was sent with topology id 0. > This is visible in StateTransferFunctionalTest, where the writing thread keeps the cpu busy and can delay the 2nd node joining for a long time (especially when run on a single core with {{taskset -c 0}}). For some reason, the PrepareCommands are sent only to the local node, while the TxCompletionNotificationCommands are sent to the entire cluster ({{null}}). When the 2nd node manages to join, it receives a lot of TxCompletionNotificationCommands and processing them delays the processing of the rebalance commands. Since the writes eventually block waiting for the new topology to be installed on the joiner, the delayed rebalance commands cause the write to time out. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015