January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5164) Deployment of marshallers on server

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5164: ------------------------------------- Summary: Deployment of marshallers on server Key: ISPN-5164 URL: https://issues.jboss.org/browse/ISPN-5164 Project: Infinispan Issue Type: Feature Request Components: Server Reporter: Tristan Tarrant Assignee: Galder Zamarreño It should be possible to deploy custom marshallers to the server so that they can be used e.g. in compatibility mode. -- 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 Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5158?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5158: ------------------------------------ After further investigation it turns out cache.withFlags(FORCE_WRITE_LOCK).get(k) is not affected. A ClusteredGetCommand with the acquireRemoteLocks=true can indeed cause a transaction rollback, but a get() will trigger a separate LockControlCommand instead of setting acquireRemoteLocks=true. Instead, the separate LockControlCommand is skipped and acquireRemoteLocks=true only for write operations with the SKIP_LOCKING flag set. I've created ISPN-5163 to describe the issue. The current fix will remove the potential rollback from ISPN-5163, but the lock will still be acquired with the SKIP_LOCKING flag. > 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 > Assignee: Dan Berindei > Priority: Critical > Attachments: tx.txt, views.txt > > > 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] > 10:01:36,135 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-9) Committing transaction GlobalTransaction:<edg-perf02-39415>:28106:local > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5163) A write operation with the SKIP_LOCKING flag can roll back the transaction

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5163: ---------------------------------- Summary: A write operation with the SKIP_LOCKING flag can roll back the transaction Key: ISPN-5163 URL: https://issues.jboss.org/browse/ISPN-5163 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.1.0.Beta1, 7.0.3.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.1.0.Final When a write operation has the SKIP_LOCKING flag, it does not send a {{LockControlCommand}} to the primary owner, but it can send a {{ClusteredGetCommand}} with {{acquireRemoteLocks=true}} instead. The {{ClusteredGetCommmand}} will then execute a {{LockControlCommand}} with the origin not set properly, and {{TxInterceptor}} will roll back the transaction because the originator ({{null}}) appears to have left the cluster. -- 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 commented on ISPN-5158: ----------------------------------- This looks like a limitation of the current fix, right? Or is there any conceptual problem with setting the origin properly? And does that mean that the locking get() will sometimes return incorrect results, sometimes fail or always fail? In both cases, could you link another JIRA + BZ to track the limitation? > 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 > Assignee: Dan Berindei > Priority: Critical > Attachments: tx.txt, views.txt > > > 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] > 10:01:36,135 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-9) Committing transaction GlobalTransaction:<edg-perf02-39415>:28106:local > {code} -- 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 ON_QA to VERIFIED > 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-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 MODIFIED to ON_QA > 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 ON_QA to VERIFIED > 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-5162) MassIndexer race condition when using sharding

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5162: --------------------------------------- Summary: MassIndexer race condition when using sharding Key: ISPN-5162 URL: https://issues.jboss.org/browse/ISPN-5162 Project: Infinispan Issue Type: Bug Components: Embedded Querying, Remote Querying Affects Versions: 7.1.0.Beta1 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes Exposed by {{ShardingMassIndexTest}} intermittent failures. Currently the search backend (hibernate search) is not capable of purging and flushing single indexes, it can only purge by entity type which in turn can involve several IndexManagers. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5161) Upgrade to protostream-3.0.0.Alpha8

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5161?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5161: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1183765|https://bugzilla.redhat.com/show_bug.cgi?id=1183765] from NEW to POST > Upgrade to protostream-3.0.0.Alpha8 > ----------------------------------- > > Key: ISPN-5161 > URL: https://issues.jboss.org/browse/ISPN-5161 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > 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-5161) Upgrade to protostream-3.0.0.Alpha8

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5161?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5161: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1183765 > Upgrade to protostream-3.0.0.Alpha8 > ----------------------------------- > > Key: ISPN-5161 > URL: https://issues.jboss.org/browse/ISPN-5161 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015