July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4527) OSGi dependencies should be "provided"

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4527: ------------------------------------- Summary: OSGi dependencies should be "provided" Key: ISPN-4527 URL: https://issues.jboss.org/browse/ISPN-4527 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: 7.0.0.Alpha4 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.0.0.Final -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4245) ConsistentHashFactory needs to be configurable via XML

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4245?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4245: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > ConsistentHashFactory needs to be configurable via XML > ------------------------------------------------------ > > Key: ISPN-4245 > URL: https://issues.jboss.org/browse/ISPN-4245 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Configuration > Affects Versions: 7.0.0.Alpha3 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > In the XML parsing changes added in ISPN-3514, I forgot to add ConsistentHashFactory configuration. This is needed in order to be able to have multiple caches with the same consistent hash. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4503) Commands with topology id 0 are not properly ignored on joiners

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4503?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4503: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2723 > Commands with topology id 0 are not properly ignored on joiners > --------------------------------------------------------------- > > Key: ISPN-4503 > URL: https://issues.jboss.org/browse/ISPN-4503 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Alpha5 > > > InboundInvocationHandlerImpl is supposed to ignore commands sent with a topology id smaller than the first topology id in which the local node was a member. But there is a loophole when the command was sent with topology id 0. > This is visible in StateTransferFunctionalTest, where the writing thread keeps the cpu busy and can delay the 2nd node joining for a long time (especially when run on a single core with {{taskset -c 0}}). For some reason, the PrepareCommands are sent only to the local node, while the TxCompletionNotificationCommands are sent to the entire cluster ({{null}}). When the 2nd node manages to join, it receives a lot of TxCompletionNotificationCommands and processing them delays the processing of the rebalance commands. Since the writes eventually block waiting for the new topology to be installed on the joiner, the delayed rebalance commands cause the write to time out. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4504: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2723 > Topology id is not properly set on ClusteredGetCommands > ------------------------------------------------------- > > Key: ISPN-4504 > URL: https://issues.jboss.org/browse/ISPN-4504 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target. > I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7:: > | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) | > | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply | > | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply | -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2522) The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2522?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2522: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2723 > The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically > --------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2522 > URL: https://issues.jboss.org/browse/ISPN-2522 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Reporter: Anna Manukyan > Assignee: Dan Berindei > Labels: testsuite_stability > > The following tests of org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest class are failing periodically during JDG 6.1.0.ER3 build testing: > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingNonTxThread > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingTxThread > You can find the failure logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The same issue happens to org.infinispan.statetranser.StateTransferFunctionTest tests(the parent test class). > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2522) The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2522?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-2522: ------------------------------------ The writing thread starts executing txs while the first node is alone in the cluster (topology id = 0). Because of ISPN-4519, prepare commands are not broadcasted between the 2nd node joining the JGroups view and the 1st starting the rebalance. But TxCompletionNotificationCommands *are* broadcasted, and they are queued on the 2nd node until it receives the REBALANCE_START command. After that, because of ISPN-4503, the queued TxCompletedNotificationCommands delay the execution of the REBALANCE_START command, and the test times out waiting for the rebalance to end. > The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically > --------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2522 > URL: https://issues.jboss.org/browse/ISPN-2522 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Reporter: Anna Manukyan > Assignee: Dan Berindei > Labels: testsuite_stability > > The following tests of org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest class are failing periodically during JDG 6.1.0.ER3 build testing: > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingNonTxThread > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingTxThread > You can find the failure logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The same issue happens to org.infinispan.statetranser.StateTransferFunctionTest tests(the parent test class). > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4506) Fix types on AdvancedCacheLoader to be friendlier for loader implementors

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4506: ----------------------------------- Fix Version/s: 7.0.0.Alpha5 7.0.0.Final > Fix types on AdvancedCacheLoader to be friendlier for loader implementors > ------------------------------------------------------------------------- > > Key: ISPN-4506 > URL: https://issues.jboss.org/browse/ISPN-4506 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Currently AdvancedCacheLoader has the following method > {code} > void process(KeyFilter<? super K> filter, CacheLoaderTask<? super K, ? super V> task, Executor executor, boolean fetchValue, boolean fetchMetadata); > {code} > The issue is that the CacheLoaderTask doesn't use the lower bound wildcard types directly. Instead it has an argument of MarshalledEntry<K, V> which means the lower bounds are applied to this Entry. Unfortunately the JVM compiler cannot do lower bounds properly on a nested type like this so it can cause issues when passing this as an argument. > Instead we should change the process method to have strong types for the CacheLoaderTask which would allow for implementors to easily implement this. This does lose the ability to pass super types for the CacheLoaderTask types, however this is unlikely to be used often and can easily be worked around while maintaining type safety. On the inverse the implementors of AdvancedCacheLoader have to resort to raw types to get it to compile. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4506) Fix types on AdvancedCacheLoader to be friendlier for loader implementors

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4506: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Fix types on AdvancedCacheLoader to be friendlier for loader implementors > ------------------------------------------------------------------------- > > Key: ISPN-4506 > URL: https://issues.jboss.org/browse/ISPN-4506 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Currently AdvancedCacheLoader has the following method > {code} > void process(KeyFilter<? super K> filter, CacheLoaderTask<? super K, ? super V> task, Executor executor, boolean fetchValue, boolean fetchMetadata); > {code} > The issue is that the CacheLoaderTask doesn't use the lower bound wildcard types directly. Instead it has an argument of MarshalledEntry<K, V> which means the lower bounds are applied to this Entry. Unfortunately the JVM compiler cannot do lower bounds properly on a nested type like this so it can cause issues when passing this as an argument. > Instead we should change the process method to have strong types for the CacheLoaderTask which would allow for implementors to easily implement this. This does lose the ability to pass super types for the CacheLoaderTask types, however this is unlikely to be used often and can easily be worked around while maintaining type safety. On the inverse the implementors of AdvancedCacheLoader have to resort to raw types to get it to compile. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4506) Fix types on AdvancedCacheLoader to be friendlier for loader implementors

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4506: ----------------------------------- Issue Type: Enhancement (was: Bug) > Fix types on AdvancedCacheLoader to be friendlier for loader implementors > ------------------------------------------------------------------------- > > Key: ISPN-4506 > URL: https://issues.jboss.org/browse/ISPN-4506 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Currently AdvancedCacheLoader has the following method > {code} > void process(KeyFilter<? super K> filter, CacheLoaderTask<? super K, ? super V> task, Executor executor, boolean fetchValue, boolean fetchMetadata); > {code} > The issue is that the CacheLoaderTask doesn't use the lower bound wildcard types directly. Instead it has an argument of MarshalledEntry<K, V> which means the lower bounds are applied to this Entry. Unfortunately the JVM compiler cannot do lower bounds properly on a nested type like this so it can cause issues when passing this as an argument. > Instead we should change the process method to have strong types for the CacheLoaderTask which would allow for implementors to easily implement this. This does lose the ability to pass super types for the CacheLoaderTask types, however this is unlikely to be used often and can easily be worked around while maintaining type safety. On the inverse the implementors of AdvancedCacheLoader have to resort to raw types to get it to compile. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4477) infinispan-server.sh grep with log message

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4477?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4477: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 7.0.0.Final Resolution: Done > infinispan-server.sh grep with log message > ------------------------------------------ > > Key: ISPN-4477 > URL: https://issues.jboss.org/browse/ISPN-4477 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > infinispan-server.sh checks whether or not the instance launched, using the following grep: > {code} > grep 'JBAS015874.*started in' $ISPN_SERVER_CONSOLE_LOG > /dev/null > {code} > But it doesn't play nicely with i18n log message and the log message is not necessary here at all. This is already fixed in WildFly, it only uses log ID. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014