February 2016 - infinispan-issues

[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4159: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases > -------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-4159 > URL: https://issues.jboss.org/browse/ISPN-4159 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1 > > > DefaultTwoWayKey2StringMapper uses two neat tricks. > 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified. > 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain. > Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it. > This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code. > Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3940) Fine-grained authorization

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3940?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3940: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Fine-grained authorization > -------------------------- > > Key: ISPN-3940 > URL: https://issues.jboss.org/browse/ISPN-3940 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.CR1 > > > Add a way to set ACL per-entry, storing it in some additional security metadata so that only users belonging to certain roles can access it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3938) AdvancedAsyncCacheLoader.process() concurrency issues

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3938?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3938: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > AdvancedAsyncCacheLoader.process() concurrency issues > ----------------------------------------------------- > > Key: ISPN-3938 > URL: https://issues.jboss.org/browse/ISPN-3938 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.CR1 > > > {{AdvancedAsyncCacheLoader.process()}} calls {{advancedLoader().process()}} to collect all the keys in the store, but the HashSet used to collect the keys it not thread-safe. This can cause problems, e.g. during state transfer: > {noformat} > WARN cheTopologyControlCommand | ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=sessions, type=CH_UPDATE, sender=alfie-lt-46127, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=60, numOwners=1, members=[alfie-lt-46127]}, pendingCH=null, throwable=null, viewId=1}java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926) > at java.util.HashMap$KeyIterator.next(HashMap.java:960) > at org.infinispan.persistence.async.AdvancedAsyncCacheLoader.process(AdvancedAsyncCacheLoader.java:80) > at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:414) > at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:910) > at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:393) > at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:178) > at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:38) > at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:100) > at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:191) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:152) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:124) > at org.infinispan.topology.ClusterTopologyManagerImpl$3.run(ClusterTopologyManagerImpl.java:606) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4624) Allow custom partition handling strategy

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4624?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4624: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Allow custom partition handling strategy > ---------------------------------------- > > Key: ISPN-4624 > URL: https://issues.jboss.org/browse/ISPN-4624 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Dan Berindei > Labels: partition_handling > Fix For: 8.2.0.CR1 > > > Users should be able to configure a custom PartitionHandlingStrategy. It should be able to specify a behaviour on merge as well. > We might want to merge this with the RebalancePolicy, which was also supposed to be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4912) Switch REST store to better HTTP client library

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4912?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4912: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Switch REST store to better HTTP client library > ----------------------------------------------- > > Key: ISPN-4912 > URL: https://issues.jboss.org/browse/ISPN-4912 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.CR1 > > > As a result of https://github.com/infinispan/infinispan/pull/3004, either OkHttp or Netty should do the trick. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4903) ServerFailureRetrySingleOwnerTest doesn't actually test client retry

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4903: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > ServerFailureRetrySingleOwnerTest doesn't actually test client retry > -------------------------------------------------------------------- > > Key: ISPN-4903 > URL: https://issues.jboss.org/browse/ISPN-4903 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Fix For: 8.2.0.CR1 > > Attachments: ServerFailureRetrySingleOwnerTest.java > > > With {{useSynchronization = true}} (the default, before ISPN-4166 is integrated), the {{SuspectException}} thrown by the listener is swallowed by the transaction manager and the client doesn't retry. The test doesn't pick that up because the exception is thrown _after_ the entry was updated in the data container (a regular SuspectException would be thrown before). > I changed the configuration to {{useSynchronization = false}}, but it didn't work because the {{SuspectException}} is wrapped in a {{CacheListenerException}}, so the client throws an exception instead of retrying. I also changed the test to use an interceptor instead of a listener, but then I got a {{ClassCastException}}: > {noformat} > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:424) > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:429) > at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:285) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:156) > at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:176) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71) ... 14 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4952) Add back in calls to NDC to push the cache name

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4952?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4952: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Add back in calls to NDC to push the cache name > ----------------------------------------------- > > Key: ISPN-4952 > URL: https://issues.jboss.org/browse/ISPN-4952 > Project: Infinispan > Issue Type: Enhancement > Reporter: William Burns > Fix For: 8.2.0.CR1 > > > JBLOGGING-106 has been resolved in 3.2.0.Beta2. After we upgrade to a version that has this fix we need to uncomment the lines in the LogFactory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4899) Update user guide regarding protobuf schema definition API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4899?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4899: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Update user guide regarding protobuf schema definition API > ---------------------------------------------------------- > > Key: ISPN-4899 > URL: https://issues.jboss.org/browse/ISPN-4899 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 7.0.0.CR2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1 > > > Describe the usage of __protobuf_metadata cache -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4846) State transfer keeps trying to fetch transaction data after the cache was stopped

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4846?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4846: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > State transfer keeps trying to fetch transaction data after the cache was stopped > --------------------------------------------------------------------------------- > > Key: ISPN-4846 > URL: https://issues.jboss.org/browse/ISPN-4846 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.CR1 > Reporter: Dan Berindei > Fix For: 8.2.0.CR1 > > > StateConsumerImpl doesn't check if the cache is stopped while fetching transaction data, it only stops when it's no longer able to find providers for transactions. > However, JGroupsTransport throws a generic CacheException when the channel is stopped. The state transfer thread can enter a busy-wait loop, retrying to get the transaction data and immediately getting the CacheException, filling the log with messages like this: > {noformat} > 19:32:28,237 WARN (remote-thread-NodeN-p42592-t1:) [StateConsumerImpl] ISPN000209: Failed to retrieve transactions for segments [10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56] of cache testCache from node NodeM-53416 > org.infinispan.commons.CacheException: java.lang.IllegalStateException: channel is not connected > at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:655) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:536) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:290) > at org.infinispan.statetransfer.StateConsumerImpl.getTransactions(StateConsumerImpl.java:766) > at org.infinispan.statetransfer.StateConsumerImpl.requestTransactions(StateConsumerImpl.java:685) > at org.infinispan.statetransfer.StateConsumerImpl.addTransfers(StateConsumerImpl.java:629) > at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:331) > at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:195) > at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:43) > at org.infinispan.statetransfer.StateTransferManagerImpl$1.rebalance(StateTransferManagerImpl.java:116) > {noformat} > We should check is the cache is stopped before retrying in StateConsumerImpl.requestTransactions. I also think we should change the stop order - it would make sense to stop the remote executor threads and the RpcDispatcher before we stop the channel. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4880) Distribution mode-friendly preloading

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4880?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4880: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Distribution mode-friendly preloading > ------------------------------------- > > Key: ISPN-4880 > URL: https://issues.jboss.org/browse/ISPN-4880 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Loaders and Stores > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Fix For: 8.2.0.CR1 > > > For non-shared stores, we need a graceful restart to make sure each node receives the exact same segments after restart, and that keys aren't readable/writable until re recover all the segments. > With a shared store, however, we could replace the implicit preload with an explicit preload that can be called by the user after the cluster is fully formed. > Currently, preloading happens before the cache is a full member of the cluster, so it wants to load every key on every node. In a large cluster, that means most of the keys loaded by preload will be discarded as it joins and finds out it owns only a tiny slice of the data. > Preloaded values might be out of date before the node becomes a full member (because writes on the existing nodes will update the shared store, but not the joiner's in-memory data). The only way to avoid that is to delete everything that was preloaded on join, meaning even more lost work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2016