July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4499: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2708 > Prevent shadowing user-defined jgroups configuration file > --------------------------------------------------------- > > Key: ISPN-4499 > URL: https://issues.jboss.org/browse/ISPN-4499 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Configuration > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > > When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files. > Proposed solution: > * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution) > * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs) > * when Infinispan is started, log the path to the configuration file used, e.g.: > {code} > 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml' > 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml' > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4506: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2707 > 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 > > 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)

11 years, 9 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4506: -------------------------------- Component/s: Loaders and Stores > 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 > > 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)

11 years, 9 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] Work on ISPN-4506 started by William Burns. > 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 > > 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)

11 years, 9 months

1
0
0 / 0

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

by William Burns (JIRA)

William Burns created ISPN-4506: ----------------------------------- Summary: 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) Reporter: William Burns Assignee: Mircea Markus 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)

11 years, 9 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4506?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-4506: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > 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) > Reporter: William Burns > Assignee: William Burns > > 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)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4505) Lucene Directory polishing

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4505?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4505: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2706 > Lucene Directory polishing > -------------------------- > > Key: ISPN-4505 > URL: https://issues.jboss.org/browse/ISPN-4505 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Lucene Directory > Affects Versions: 7.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Minor > > Since we are not supporting multiple versions of Lucene simultaneously anymore, we can remove a couple of layers from it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4498) OutOfMemoryError when CI is ran with tracing

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4498?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4498: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2704 > OutOfMemoryError when CI is ran with tracing > -------------------------------------------- > > Key: ISPN-4498 > URL: https://issues.jboss.org/browse/ISPN-4498 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha4 > Reporter: William Burns > Assignee: William Burns > > The CI will fail very often when tracing is enabled with some sort of OOM error. > http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_MasterHotsp... > Looking closer this appears to be an issue with an accumulation of Threads. These threads aren't running either but rather are held in memory unneedingly. It appears that they are being retained in the log4j1.2 NDC class in it's hashtable. Upon further investigation we never call to NDC.remove which would clear up the current any dead threads. > I have crated JBLOGGING-106 to fix this as well. In the mean time we shouldn't use NDC. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4505) Lucene Directory polishing

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-4505: --------------------------------------- Summary: Lucene Directory polishing Key: ISPN-4505 URL: https://issues.jboss.org/browse/ISPN-4505 Project: Infinispan Issue Type: Task Security Level: Public (Everyone can see) Components: Lucene Directory Affects Versions: 7.0.0.Alpha4 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes Priority: Minor Since we are not supporting multiple versions of Lucene simultaneously anymore, we can remove a couple of layers from it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 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: ------------------------------- Description: 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 | was: 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:: | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply | | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply | > 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)

11 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014