December 2015 - infinispan-issues

[JBoss JIRA] (ISPRK-3) Infinispan Query DSL from my Spark application

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPRK-3?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated ISPRK-3: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Infinispan Query DSL from my Spark application > ---------------------------------------------- > > Key: ISPRK-3 > URL: https://issues.jboss.org/browse/ISPRK-3 > Project: Infinispan Spark > Issue Type: Feature Request > Components: RDD > Affects Versions: 0.1 > Reporter: Pedro Zapata > Assignee: Gustavo Fernandes > Labels: jdg7 > Fix For: 0.2 > > > As an application developer, I want to use Infinispan Query DSL from my Spark application written in Java. > Once Java is supported, Scala can be supported as well, no extra effort required -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5623: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3873 (was: https://github.com/infinispan/infinispan/pull/3863) > Retried prepare commands do not wait for backup locks > ----------------------------------------------------- > > Key: ISPN-5623 > URL: https://issues.jboss.org/browse/ISPN-5623 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.1.0.Final > > Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java > > > When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. > That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. > This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6003) Reduce number of allocations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6003?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6003: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > Reduce number of allocations > ---------------------------- > > Key: ISPN-6003 > URL: https://issues.jboss.org/browse/ISPN-6003 > Project: Infinispan > Issue Type: Task > Components: Core, Server > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 8.1.0.Final > > > Profiling revealed some allocations that are easy to remove: > * The HotRod operations factory stores a list of flags in a thread-local. The thread-local can be removed, and the flags can be stored in an {{int}}. > * JGroupsTransport copies the list of members to check if a broadcast should be sent as a unicast, and the copy is then discarded. > * ExtendedByteBuf could use {{Array.empty}} instead of {{Array[Byte]()}}. > * DecoratedCache could avoid calling {{Arrays.asList()}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6002) Cache log.isTraceEnabled() as much as possible

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6002?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6002: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > Cache log.isTraceEnabled() as much as possible > ---------------------------------------------- > > Key: ISPN-6002 > URL: https://issues.jboss.org/browse/ISPN-6002 > Project: Infinispan > Issue Type: Task > Components: Core, Server > Affects Versions: 8.1.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 8.1.0.Final > > > With log4j2 it's not that big of a problem, but there are still environments where this could make a difference (i.e. in the server). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5860) ComponentRegistry should cache the VersionGenerator in a field

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5860?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5860: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > ComponentRegistry should cache the VersionGenerator in a field > -------------------------------------------------------------- > > Key: ISPN-5860 > URL: https://issues.jboss.org/browse/ISPN-5860 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The {{VersionGenerator}} component is read by the HotRod server for each write operation, and we can optimize it by caching the component in a field. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5859) HotRod server should not use privileged actions for common stuff

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5859?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5859: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > HotRod server should not use privileged actions for common stuff > ---------------------------------------------------------------- > > Key: ISPN-5859 > URL: https://issues.jboss.org/browse/ISPN-5859 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The HotRod server uses privileged actions to perform operations that are needed for each request, like reading the cache mode to decide what kind (if any) topology update to send to the client. Since privileged actions use thread-locals, we should try to avoid them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5858) ValueMatcher and AvailabilityMode should have externalizers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5858?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5858: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > ValueMatcher and AvailabilityMode should have externalizers > ----------------------------------------------------------- > > Key: ISPN-5858 > URL: https://issues.jboss.org/browse/ISPN-5858 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.CR1 > > > The default enum serialization is pretty bad, it writes both the enum name and value name as strings. > {{ValueMatcher}} is needed in each write command, so we should optimize it. > {{AvailabilityMode}} doesn't matter that much, except when the coordinator changes, and the new coordinator has to retrieve the status of all the caches on all the nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5857) HotRod client should use the consistent hash in replicated mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5857?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5857: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > HotRod client should use the consistent hash in replicated mode > --------------------------------------------------------------- > > Key: ISPN-5857 > URL: https://issues.jboss.org/browse/ISPN-5857 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: hotrod > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The HotRod server assumes that in replicated mode the server accessed by the client doesn't matter, so it doesn't send a consistent hash in the topology updates. > However, since replicated mode is now implemented on top of distributed mode, hitting the primary owner or another node makes a big difference. We should change the server to send the consistent hash for replicated caches as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5922) Recovery MBean showInDoubtTransactions fails because of missing RecoveryManager

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5922?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5922: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Final Resolution: Done > Recovery MBean showInDoubtTransactions fails because of missing RecoveryManager > -------------------------------------------------------------------------------- > > Key: ISPN-5922 > URL: https://issues.jboss.org/browse/ISPN-5922 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, Transactions > Reporter: Tristan Tarrant > Assignee: Pedro Ruivo > Labels: jdg6 > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5883) Node can apply new topology after sending status response

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5883?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5883: ------------------------------------ I missed one case in my pull request: the node applying a topology update after sending a status response could be the coordinator itself. If the coordinator after the merge is also the coordinator of a pre-merge partition, waiting for the view and checking the coordinator doesn't help. We could fix this either on the ClusterTopologyManager side or on the LocalTopologyManager side: * Cluster status recovery could include the topologies sent out by the coordinator, but not yet received by the members (from ClusterCacheStatus). * A member could refuse to apply topology updates with a view id smaller than the view id of the latest cluster status request. > Node can apply new topology after sending status response > --------------------------------------------------------- > > Key: ISPN-5883 > URL: https://issues.jboss.org/browse/ISPN-5883 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.0.1.Final, 7.2.5.Final, 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 8.1.0.Final > > > {{LocalTopologyManagerImpl}} is responsible for sending the {{ClusterTopologyControlCommand(GET_STATUS)}} response, and when it sends the response it doesn't check the current view id against the new coordinator's view id. If the old coordinator already sent a topology update before the merge, that topology update might be processed after sending the status response. The new coordinator will send a topology update with a topology id of {{max(status response topology ids) + 1}}. The node will then process the topology update from the old coordinator, but it will ignore the topology update from the new coordinator with the same topology id. > This is extra common in the partition handling tests, e.g. {{BasePessimisticTxPartitionAndMergeTest}} subclasses, because the test "injects" the JGroups view on each node serially, and often the 4th node sends the status response before it gets the new view. > {noformat} > 22:16:37,776 DEBUG (remote-thread-NodeD-p26-t6:[]) [LocalTopologyManagerImpl] Sending cluster status response for view 10 > // Topology from NodeC > 22:16:37,778 DEBUG (transport-thread-NodeD-p28-t2:[]) [LocalTopologyManagerImpl] Updating local topology for cache pes-cache: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeC-46467, NodeD-30486]} > // Later, topology from NodeA > 22:16:37,827 DEBUG (transport-thread-NodeD-p28-t1:[]) [LocalTopologyManagerImpl] Ignoring late consistent hash update for cache pes-cache, current topology is 8: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeA-37631, NodeB-47846, NodeC-46467, NodeD-30486]} > {noformat} > As a solution, we can delay sending the status response until we have the same view as the coordinator (or a later one). We already check that the sender is the current coordinator before applying a topology update, so this will guarantee that the we don't apply other topology updates from the old coordinator. Since the status request is only sent after the new view was installed, this will not introduce any delays in the vast majority of cases. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2015