[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2575:
----------------------------------
Issue Type: Enhancement (was: Bug)
> KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2575
> URL: https://issues.jboss.org/browse/ISPN-2575
> Project: Infinispan
> Issue Type: Enhancement
> Components: Querying
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Final
>
> Attachments: ClusteredCacheTest.java
>
>
> The case is the following:
> I have a clustered cache on which I want to perform a search. I'm doing the following:
> I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception:
> java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
> When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager.
> The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-1790) Release script should not rip off comments from POM.XML files
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-1790?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-1790:
----------------------------------
Issue Type: Enhancement (was: Bug)
Priority: Minor (was: Major)
> Release script should not rip off comments from POM.XML files
> -------------------------------------------------------------
>
> Key: ISPN-1790
> URL: https://issues.jboss.org/browse/ISPN-1790
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build process
> Affects Versions: 5.1.0.FINAL
> Reporter: Sanne Grinovero
> Assignee: Manik Surtani
> Priority: Minor
> Labels: release.py
> Fix For: 6.0.0.Final
>
>
> Comparing the git commit which was used to release 5.1.0.Final to the final tag of the released version, reveals some changes which are likely unintended:
> * All Copyright statements removed
> * All comments removed (useful and unuseful)
> * In some way changed the inlined scripts for Google analytics - not sure if it's still working
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3092) AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3092?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3092:
---------------------------------------
This was fixed in Hibernate Search, the dependency upgrade should solve the problem.
> AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
> -----------------------------------------------------------------------------
>
> Key: ISPN-3092
> URL: https://issues.jboss.org/browse/ISPN-3092
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Wouter De Borger
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.CR1
>
>
> When hibernate search is used (with capedwarf for example), adding a fourth server to the cluster crashes infinispan.
> I've narrowed the problem down to org.hibernate.search.backend.impl.jgroups.AutoNodeSelector:78
> Here the following formula is used to calculate an array index
> int selectionRange = members.size() - 1;
> int selected = ( indexName.hashCode() % selectionRange) + 1;
> if indexname is long (like "default_taskworker-java__com.google.appengine.api.datastore.Entity")
> the hashcode becomes negative due to integer overflow, resulting in a negative index
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3092) AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3092?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero resolved ISPN-3092.
-----------------------------------
Resolution: Done
> AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
> -----------------------------------------------------------------------------
>
> Key: ISPN-3092
> URL: https://issues.jboss.org/browse/ISPN-3092
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Wouter De Borger
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.CR1
>
>
> When hibernate search is used (with capedwarf for example), adding a fourth server to the cluster crashes infinispan.
> I've narrowed the problem down to org.hibernate.search.backend.impl.jgroups.AutoNodeSelector:78
> Here the following formula is used to calculate an array index
> int selectionRange = members.size() - 1;
> int selected = ( indexName.hashCode() % selectionRange) + 1;
> if indexname is long (like "default_taskworker-java__com.google.appengine.api.datastore.Entity")
> the hashcode becomes negative due to integer overflow, resulting in a negative index
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3092) AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3092?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-3092:
----------------------------------
Fix Version/s: 5.3.0.CR1
Component/s: Querying
> AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
> -----------------------------------------------------------------------------
>
> Key: ISPN-3092
> URL: https://issues.jboss.org/browse/ISPN-3092
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Wouter De Borger
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.CR1
>
>
> When hibernate search is used (with capedwarf for example), adding a fourth server to the cluster crashes infinispan.
> I've narrowed the problem down to org.hibernate.search.backend.impl.jgroups.AutoNodeSelector:78
> Here the following formula is used to calculate an array index
> int selectionRange = members.size() - 1;
> int selected = ( indexName.hashCode() % selectionRange) + 1;
> if indexname is long (like "default_taskworker-java__com.google.appengine.api.datastore.Entity")
> the hashcode becomes negative due to integer overflow, resulting in a negative index
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3092) AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3092?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero reassigned ISPN-3092:
-------------------------------------
Assignee: Sanne Grinovero (was: Mircea Markus)
> AutoNodeSelector throws ArrayIndexOutOfBoundsException when indexName is long
> -----------------------------------------------------------------------------
>
> Key: ISPN-3092
> URL: https://issues.jboss.org/browse/ISPN-3092
> Project: Infinispan
> Issue Type: Bug
> Reporter: Wouter De Borger
> Assignee: Sanne Grinovero
>
> When hibernate search is used (with capedwarf for example), adding a fourth server to the cluster crashes infinispan.
> I've narrowed the problem down to org.hibernate.search.backend.impl.jgroups.AutoNodeSelector:78
> Here the following formula is used to calculate an array index
> int selectionRange = members.size() - 1;
> int selected = ( indexName.hashCode() % selectionRange) + 1;
> if indexname is long (like "default_taskworker-java__com.google.appengine.api.datastore.Entity")
> the hashcode becomes negative due to integer overflow, resulting in a negative index
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3145) DataRehashedEventTest intermittent failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3145:
----------------------------------
Summary: DataRehashedEventTest intermittent failures
Key: ISPN-3145
URL: https://issues.jboss.org/browse/ISPN-3145
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Affects Versions: 5.3.0.Beta2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.3.0.CR1
DataRehashedEventTest sometimes fails because of ISPN-3035.
But other times it fails because it doesn't wait enough for the rehash event listener to be called:
{noformat}
2013-05-28 11:21:36,550 TRACE (asyncTransportThread-2,NodeA) [org.infinispan.statetransfer.DataRehashedEventTest] New event received: EventImpl{type=DATA_REHASHED, pre=true, cache=Cache '___defaultcache'@NodeA-19135, consistentHashAtStart=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-19135]}, consistentHashAtEnd=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-19135, NodeB-23459]}, newTopologyId=1}
2013-05-28 11:21:36,661 TRACE (testng-DataRehashedEventTest) [org.infinispan.test.TestingUtil] Node NodeA-19135 finished state transfer.
2013-05-28 11:21:36,661 TRACE (testng-DataRehashedEventTest) [org.infinispan.test.TestingUtil] Node NodeB-23459 finished state transfer.
2013-05-28 11:21:36,662 ERROR (testng-DataRehashedEventTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Test testJoinAndLeave(org.infinispan.statetransfer.DataRehashedEventTest) failed.
java.lang.AssertionError: expected [2] but found [1]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at org.testng.Assert.assertEquals(Assert.java:380)
at org.infinispan.statetransfer.DataRehashedEventTest.testJoinAndLeave(DataRehashedEventTest.java:73)
...
2013-05-28 11:21:36,670 TRACE (asyncTransportThread-4,NodeA) [org.infinispan.statetransfer.DataRehashedEventTest] New event received: EventImpl{type=DATA_REHASHED, pre=false, cache=Cache '___defaultcache'@NodeA-19135, consistentHashAtStart=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-19135]}, consistentHashAtEnd=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-19135, NodeB-23459]}, newTopologyId=2}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3120) StateConsumerImpl can ignore state received during a rebalance
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3120?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3120:
-------------------------------
Status: Pull Request Sent (was: Pull Request Sent)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1826, https://github.com/infinispan/infinispan/pull/1847 (was: https://github.com/infinispan/infinispan/pull/1826)
A node should not confirm that it finished receiving state before it
finished restarting broken transfer tasks.
> StateConsumerImpl can ignore state received during a rebalance
> --------------------------------------------------------------
>
> Key: ISPN-3120
> URL: https://issues.jboss.org/browse/ISPN-3120
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 5.2.7.Final, 5.3.0.CR1, 5.3.0.Final
>
>
> This causes random failures in ConcurrentOverlappingLeaveTest and ConcurrentNonOverlappingLeaveTest.
> 1. Starting with a 4-node cluster: [E, F, G, H] (topology 7).
> 2. F leaves, and E sends a REBALANCE_START command with nodes [E, G, H] (topology 8). Some segments are owned by [H] in the current CH and by [H, G] in the pending CH.
> 3. E reports that it finished receiving state with a REBAlANCE_CONFIRM command.
> 4. H leaves, and E sends a CH_UPDATE command with nodes [E, G] (topology 9).
> The segments that were owned by [H] in the previous currentCH are assigned to [E, G] in the new currentCH (otherwise they wouldn't have any owners).
> 5. The StateConsumerImpl on E requests state for the "lost" segments from G.
> 6. G confirms the end of the rebalance as well, and E sends a CH_UPDATE command to end the rebalance (topology 10).
> 7. E sends a REBALANCE_START command to assign all segments for [E, G] (topology 11).
> 8. While the StateConsumerImpl on E is starting the state transfer, it also receives a StateResponseCommand for the lost segments from G.
> 9. Because the structures keeping track of the received state are not properly initialized, E considers it finished receiving state for topology 11.
> 10. E receives a StateResponseCommand from G with actual data, but it ignores it because {{StateConsumerImpl.updatedKeys == null}}.
> {noformat}
> 11:30:39,807 DEBUG (transport-thread-4,NodeE:dist) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache dist: new topology = CacheTopology{id=7, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}, pendingCH=null}
> 11:30:39,810 DEBUG (transport-thread-3,NodeE:dist) [LocalTopologyManagerImpl] Starting local rebalance for cache dist, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}}
> 11:30:39,817 DEBUG (transport-thread-3,NodeE:dist) [StateConsumerImpl] Finished receiving of segments for cache dist for topology 8.
> 11:30:39,832 DEBUG (transport-thread-4,NodeE:dist) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache dist: new topology = CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}}
> 11:30:39,834 DEBUG (transport-thread-4,NodeE:dist) [StateConsumerImpl] Adding inbound state transfer for segments [38, 36, 47, 44, 45] of cache dist
> 11:30:39,853 DEBUG (transport-thread-3,NodeE:dist) [LocalTopologyManagerImpl] Starting local rebalance for cache dist, topology = CacheTopology{id=11, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}}
> 11:30:39,859 TRACE (remote-thread-1,NodeE:) [InboundInvocationHandlerImpl] Calling perform() on StateResponseCommand{cache=dist, origin=NodeG-6339, topologyId=9}
> 11:30:39,864 DEBUG (remote-thread-1,NodeE:dist) [StateConsumerImpl] Finished receiving of segments for cache dist for topology 11.
> 11:30:39,866 TRACE (transport-thread-5,NodeE:dist) [LocalTopologyManagerImpl] Ignoring consistent hash update 10 for cache dist, we have already received a newer topology 11
> 11:30:39,868 TRACE (remote-thread-1,NodeE:) [InboundInvocationHandlerImpl] Calling perform() on StateResponseCommand{cache=dist, origin=NodeG-6339, topologyId=11}
> 11:30:39,872 TRACE (remote-thread-1,NodeE:dist dist) [EntryWrappingInterceptor] State transfer will not write key/value MagicKey#k3{672f69c9@NodeG-6339}/v3 because it was already updated by somebody else
> 11:30:40,582 ERROR (testng-ConcurrentNonOverlappingLeaveTest:) [UnitTestTestNGListener] Test testTransactional(org.infinispan.distribution.rehash.ConcurrentNonOverlappingLeaveTest) failed.
> java.lang.AssertionError: Fail on owner cache NodeE-51027: dc.get(MagicKey#k3{672f69c9@NodeG-6339}) returned null!
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months