July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4481) Use UNICAST3 and NAKACK2 in the default server configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4481?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4481: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1116105|https://bugzilla.redhat.com/show_bug.cgi?id=1116105] from NEW to CLOSED > Use UNICAST3 and NAKACK2 in the default server configuration > ------------------------------------------------------------ > > Key: ISPN-4481 > URL: https://issues.jboss.org/browse/ISPN-4481 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > We switched to UNICAST3 a while back in the default embedded configuration, we should switch the server configuration as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4481) Use UNICAST3 and NAKACK2 in the default server configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4481?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4481: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1116967|https://bugzilla.redhat.com/show_bug.cgi?id=1116967] from NEW to MODIFIED > Use UNICAST3 and NAKACK2 in the default server configuration > ------------------------------------------------------------ > > Key: ISPN-4481 > URL: https://issues.jboss.org/browse/ISPN-4481 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > We switched to UNICAST3 a while back in the default embedded configuration, we should switch the server configuration as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4431) CLI codecs do set entry version in metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4431?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4431: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1116246|https://bugzilla.redhat.com/show_bug.cgi?id=1116246] from POST to CLOSED > CLI codecs do set entry version in metadata > ------------------------------------------- > > Key: ISPN-4431 > URL: https://issues.jboss.org/browse/ISPN-4431 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha5 > > > When the CLI writes to the cache using one of the server codecs it must set a version, because the server protocol handlers expect to find it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4484) Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4484?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4484: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from MODIFIED to ON_QA > Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command > ------------------------------------------------------------------------ > > Key: ISPN-4484 > URL: https://issues.jboss.org/browse/ISPN-4484 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha5 > > > This appeared during the 32-nodes elasticity test in the Hyperion environment. > Just as apex947 left, it started a rebalance, which apex948 dutifully cancelled as it became the new coordinator. apex949 had already requested segments from apex959, so it sent a StateRequestCommand(CANCEL_STATE_TRANSFER) asynchronously to apex959. Then apex948 started a new rebalance, and apex949 asked apex959 for the same segments. When apex959 finally received the cancel request, it didn't check the topology id and it incorrectly cancelled the outbound transfer to apex949. > The solution would be to verify the topology id in the CANCEL_STATE_TRANSFER command before cancelling the transfer. I also think we can avoid sending the cancel command completely in this case, and only send it as we are about to stop. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4480) Messages sent to leavers can clog the JGroups bundler thread

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4480?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4480: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from MODIFIED to ON_QA > Messages sent to leavers can clog the JGroups bundler thread > ------------------------------------------------------------ > > Key: ISPN-4480 > URL: https://issues.jboss.org/browse/ISPN-4480 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > > In a stress test that repeatedly kills nodes while performing read/write operations, the TransferQueueBundler thread seems to spend a lot of time waiting for physical addresses: > {noformat} > 06:40:10,316 WARN [org.radargun.utils.Utils] (pool-5-thread-1) Stack for thread TransferQueueBundler,default,apex953-14666: > java.lang.Thread.sleep(Native Method) > org.jgroups.util.Util.sleep(Util.java:1504) > org.jgroups.util.Util.sleepRandom(Util.java:1574) > org.jgroups.protocols.TP.sendToSingleMember(TP.java:1685) > org.jgroups.protocols.TP.doSend(TP.java:1670) > org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2476) > org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2392) > org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2383) > java.lang.Thread.run(Thread.java:744) > {noformat} > There are 2 bugs related to this already fixed in JGroups 3.5.0.Beta2+: JGRP-1814, JGRP-1815 > There is also a special case where the physical address could be removed from the cache too soon, exacerbating the effect of JGRP-1815: JGRP-1858 > We can work around the problem by changing the JGroups configuration: > * TP.logical_addr_cache_expiration=86400000 > ** Only expire addresses after 1 day > * TP.physical_addr_max_fetch_attempts=1 > ** Sleep for only 20ms waiting for the physical address (default 3 - 1500ms) > * UNICAST3_conn_close_timeout=10000 > ** Drop the pending messages to leavers sooner -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4154) Cancelled segment transfer causes future entry transfer to be ignored

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4154?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4154: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from MODIFIED to ON_QA > Cancelled segment transfer causes future entry transfer to be ignored > --------------------------------------------------------------------- > > Key: ISPN-4154 > URL: https://issues.jboss.org/browse/ISPN-4154 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > > Distributed transactional cache. > 1) Coordinator is gracefully leaving the cluster, sends a REBALANCE_START with topologyId 14, ST begins. > 2) Node receives chunk from segment X, writes entry K=V to the container. > 3) New coordinator jumps in with CH_UPDATE topology 16 > 4) Node receives CANCEL_STATE_TRANSFER and cancels transfer of segment X, invalidating K. In CommitManager, this operation is tracked and DiscardPolicy is set to DISCARD_STATE_TRANSFER for key K. > 5) New coordinator starts rebalance with topology 17 > 6) Node starts new ST for segment X > 7) Node receives the X: K=V, but in CommitManager it finds out that the policy is set to DISCARD_STATE_TRANSFER and ignores this update. > Result: entry value is lost on some node. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4467) keySet operation via HotRod in compatibility mode throws ClassCastException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4467?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4467: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1112886|https://bugzilla.redhat.com/show_bug.cgi?id=1112886] from NEW to ON_QA > keySet operation via HotRod in compatibility mode throws ClassCastException > --------------------------------------------------------------------------- > > Key: ISPN-4467 > URL: https://issues.jboss.org/browse/ISPN-4467 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > The HotRod client's keySet() operation throws ClassCastException due to the following reason: > When Encoder2x.scala in its writeResponse() method decodes the operation as BulkGetKeysResponse, it runs a Map/Reduce job that returns a set of keys in the whole cluster. > The operation returns a set of "unmarshalled" (cos we're in compatibility mode) entries. However, Scala infers the type of individual entries as "Bytes" which is an alias for Array[Byte]. > As a result, when this iterator from this key set is retrieved, it is not possible to iterate through the entries because Scala automatically tries to convert each (unmarshalled) entry into a byte array, which results in the exception. > This line results in throwing CCE: > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4438) Entry is not properly unmarshalled by HotRod client in compatibility mode when L1 enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4438?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4438: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1112886|https://bugzilla.redhat.com/show_bug.cgi?id=1112886] from NEW to ON_QA > Entry is not properly unmarshalled by HotRod client in compatibility mode when L1 enabled > ----------------------------------------------------------------------------------------- > > Key: ISPN-4438 > URL: https://issues.jboss.org/browse/ISPN-4438 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > When a distributed cache is used together with compatibility mode and L1 is enabled. The entry being returned to the client is not unmarshalled when it is found in the L1 cache. Unmarshalling works fine if the entry is retrieved from a remote node (not found in L1). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4437) L1 cache is enabled by default in server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4437?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4437: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1112886|https://bugzilla.redhat.com/show_bug.cgi?id=1112886] from NEW to ON_QA > L1 cache is enabled by default in server > ---------------------------------------- > > Key: ISPN-4437 > URL: https://issues.jboss.org/browse/ISPN-4437 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > When a distributed cache is used in the server, L1 cache is enabled and the lifespan is 10 mins even if L1 is not configured in standalone.xml file. > This is not an expected behaviour and should be changed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4451) Missing ACCESS right

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4451?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4451: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1113872|https://bugzilla.redhat.com/show_bug.cgi?id=1113872] from MODIFIED to ON_QA > Missing ACCESS right > -------------------- > > Key: ISPN-4451 > URL: https://issues.jboss.org/browse/ISPN-4451 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > > When security is turned on ({{cacheConfig.security().authorization().enable()}}), any user can obtain/create a cache, even unauthorized users. This should be allowed only for users with right {{ACCESS}}. This right is actually not present in {{AuthorizationPermission}}. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014