January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5158) Transaction rolled back but returns successful response

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5158?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5158: ------------------------------ Priority: Critical (was: Major) > Transaction rolled back but returns successful response > ------------------------------------------------------- > > Key: ISPN-5158 > URL: https://issues.jboss.org/browse/ISPN-5158 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.1.0.Beta1 > Reporter: Radim Vansa > Priority: Critical > > When the cluster is merging, it is possible that a node is removed from the view although it is still responsive. Eventually the cluster is merged correctly, but since the node is reported as missing from the view, transaction originating from this node is rolled back. > {code} > 10:01:36,116 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-151) Rolling back remote transaction GlobalTransaction:<edg-perf02-39415>:28106:remote because either already completed(false) or originator no longer in the cluster(true). > {code} > However, even after this a successful response is sent to the originator: > {code} > 10:01:36,119 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-151) About to send back response null for command PrepareCommand {modifications=[PutKeyValueCommand{key=key_0000000000001318, value=[19 #1: 1195, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, gtx=GlobalTransaction:<edg-perf02-39415>:28106:remote, cacheName='testCache', topologyId=47} > {code} > Originator then expects that the transaction was successfully prepared: > {code} > 10:01:36,124 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-9) Responses: [sender=edg-perf01-36235, received=true, suspected=false] > [sender=edg-perf03-24110, received=true, suspected=false] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5158) Transaction rolled back but returns successful response

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5158?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5158: ------------------------------ Affects Version/s: 7.1.0.Beta1 > Transaction rolled back but returns successful response > ------------------------------------------------------- > > Key: ISPN-5158 > URL: https://issues.jboss.org/browse/ISPN-5158 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.1.0.Beta1 > Reporter: Radim Vansa > Priority: Critical > > When the cluster is merging, it is possible that a node is removed from the view although it is still responsive. Eventually the cluster is merged correctly, but since the node is reported as missing from the view, transaction originating from this node is rolled back. > {code} > 10:01:36,116 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-151) Rolling back remote transaction GlobalTransaction:<edg-perf02-39415>:28106:remote because either already completed(false) or originator no longer in the cluster(true). > {code} > However, even after this a successful response is sent to the originator: > {code} > 10:01:36,119 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-151) About to send back response null for command PrepareCommand {modifications=[PutKeyValueCommand{key=key_0000000000001318, value=[19 #1: 1195, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, gtx=GlobalTransaction:<edg-perf02-39415>:28106:remote, cacheName='testCache', topologyId=47} > {code} > Originator then expects that the transaction was successfully prepared: > {code} > 10:01:36,124 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-9) Responses: [sender=edg-perf01-36235, received=true, suspected=false] > [sender=edg-perf03-24110, received=true, suspected=false] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5158) Transaction rolled back but returns successful response

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5158?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5158: ------------------------------ Component/s: Core > Transaction rolled back but returns successful response > ------------------------------------------------------- > > Key: ISPN-5158 > URL: https://issues.jboss.org/browse/ISPN-5158 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.Beta1 > Reporter: Radim Vansa > Priority: Critical > > When the cluster is merging, it is possible that a node is removed from the view although it is still responsive. Eventually the cluster is merged correctly, but since the node is reported as missing from the view, transaction originating from this node is rolled back. > {code} > 10:01:36,116 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-151) Rolling back remote transaction GlobalTransaction:<edg-perf02-39415>:28106:remote because either already completed(false) or originator no longer in the cluster(true). > {code} > However, even after this a successful response is sent to the originator: > {code} > 10:01:36,119 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-151) About to send back response null for command PrepareCommand {modifications=[PutKeyValueCommand{key=key_0000000000001318, value=[19 #1: 1195, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, gtx=GlobalTransaction:<edg-perf02-39415>:28106:remote, cacheName='testCache', topologyId=47} > {code} > Originator then expects that the transaction was successfully prepared: > {code} > 10:01:36,124 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-9) Responses: [sender=edg-perf01-36235, received=true, suspected=false] > [sender=edg-perf03-24110, received=true, suspected=false] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5158) Transaction rolled back but returns successful response

by Radim Vansa (JIRA)

Radim Vansa created ISPN-5158: --------------------------------- Summary: Transaction rolled back but returns successful response Key: ISPN-5158 URL: https://issues.jboss.org/browse/ISPN-5158 Project: Infinispan Issue Type: Feature Request Reporter: Radim Vansa When the cluster is merging, it is possible that a node is removed from the view although it is still responsive. Eventually the cluster is merged correctly, but since the node is reported as missing from the view, transaction originating from this node is rolled back. {code} 10:01:36,116 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-151) Rolling back remote transaction GlobalTransaction:<edg-perf02-39415>:28106:remote because either already completed(false) or originator no longer in the cluster(true). {code} However, even after this a successful response is sent to the originator: {code} 10:01:36,119 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-151) About to send back response null for command PrepareCommand {modifications=[PutKeyValueCommand{key=key_0000000000001318, value=[19 #1: 1195, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, gtx=GlobalTransaction:<edg-perf02-39415>:28106:remote, cacheName='testCache', topologyId=47} {code} Originator then expects that the transaction was successfully prepared: {code} 10:01:36,124 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-9) Responses: [sender=edg-perf01-36235, received=true, suspected=false] [sender=edg-perf03-24110, received=true, suspected=false] {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5158) Transaction rolled back but returns successful response

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5158?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5158: ------------------------------ Issue Type: Bug (was: Feature Request) > Transaction rolled back but returns successful response > ------------------------------------------------------- > > Key: ISPN-5158 > URL: https://issues.jboss.org/browse/ISPN-5158 > Project: Infinispan > Issue Type: Bug > Reporter: Radim Vansa > > When the cluster is merging, it is possible that a node is removed from the view although it is still responsive. Eventually the cluster is merged correctly, but since the node is reported as missing from the view, transaction originating from this node is rolled back. > {code} > 10:01:36,116 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-151) Rolling back remote transaction GlobalTransaction:<edg-perf02-39415>:28106:remote because either already completed(false) or originator no longer in the cluster(true). > {code} > However, even after this a successful response is sent to the originator: > {code} > 10:01:36,119 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-151) About to send back response null for command PrepareCommand {modifications=[PutKeyValueCommand{key=key_0000000000001318, value=[19 #1: 1195, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, gtx=GlobalTransaction:<edg-perf02-39415>:28106:remote, cacheName='testCache', topologyId=47} > {code} > Originator then expects that the transaction was successfully prepared: > {code} > 10:01:36,124 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-9) Responses: [sender=edg-perf01-36235, received=true, suspected=false] > [sender=edg-perf03-24110, received=true, suspected=false] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3824) Upgrade to Narayana 5.0.4

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3824?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3824: ---------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/3226 (was: https://github.com/infinispan/infinispan/pull/3202) > Upgrade to Narayana 5.0.4 > ------------------------- > > Key: ISPN-3824 > URL: https://issues.jboss.org/browse/ISPN-3824 > Project: Infinispan > Issue Type: Component Upgrade > Components: Transactions > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 7.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3718: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1172107|https://bugzilla.redhat.com/show_bug.cgi?id=1172107] from ASSIGNED to MODIFIED > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.0.0.Final > > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4820) Change Size method on Cache to return the contents of the entire cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4820?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4820: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1157390|https://bugzilla.redhat.com/show_bug.cgi?id=1157390] from ASSIGNED to ON_QA > Change Size method on Cache to return the contents of the entire cluster > ------------------------------------------------------------------------ > > Key: ISPN-4820 > URL: https://issues.jboss.org/browse/ISPN-4820 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR2 > > > It has been discussed to change the size method to properly reflect the contents of the entire cache instead of just locally. > http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015524.html > It seems for now we should do this via the entry iterator for distributed caches otherwise use current implementation for local. Or something of that sort. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4820) Change Size method on Cache to return the contents of the entire cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4820?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4820: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1157390|https://bugzilla.redhat.com/show_bug.cgi?id=1157390] from MODIFIED to ASSIGNED > Change Size method on Cache to return the contents of the entire cluster > ------------------------------------------------------------------------ > > Key: ISPN-4820 > URL: https://issues.jboss.org/browse/ISPN-4820 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR2 > > > It has been discussed to change the size method to properly reflect the contents of the entire cache instead of just locally. > http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015524.html > It seems for now we should do this via the entry iterator for distributed caches otherwise use current implementation for local. Or something of that sort. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4771) Combine doclets to avoid running javadocs multiple times

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4771?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4771: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1164688|https://bugzilla.redhat.com/show_bug.cgi?id=1164688] from ON_QA to ASSIGNED > Combine doclets to avoid running javadocs multiple times > -------------------------------------------------------- > > Key: ISPN-4771 > URL: https://issues.jboss.org/browse/ISPN-4771 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The PublicAPIDoclet and JMXDoclet doclets should be combined so that they only require one pass -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 January 2015