July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1986) Make putForExternalRead return a boolean instead of void

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1986?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1986: -------------------------------- Fix Version/s: 6.0.0.Beta2 > Make putForExternalRead return a boolean instead of void > -------------------------------------------------------- > > Key: ISPN-1986 > URL: https://issues.jboss.org/browse/ISPN-1986 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > Related to ISPN-1983 and https://hibernate.onjira.com/browse/HHH-7256, I'd like to change the API of putForExternalRead() to return a boolean instead of void. > The reason for doing this is to be able to find out if the PFER did actually end up storing something or not. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1396) Make all ExecutorServices configurable via global configuration

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1396?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1396: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Make all ExecutorServices configurable via global configuration > --------------------------------------------------------------- > > Key: ISPN-1396 > URL: https://issues.jboss.org/browse/ISPN-1396 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > > Several executor services are not configurable out of the box, which could complicate AS7 management. > For example: > - RehashExecutor (BaseStateTransferManagerImpl, see ISPN-1194) > - LockBreakingService (in TransactionTable) > - CoalescedAsyncStore (in AsyncStore) -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2201) Make a distinction between user-level and internal flags

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2201?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2201: -------------------------------- Fix Version/s: (was: 6.0.0.Final) (was: 6.0.0.Alpha1) > Make a distinction between user-level and internal flags > -------------------------------------------------------- > > Key: ISPN-2201 > URL: https://issues.jboss.org/browse/ISPN-2201 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > This confusion is highlighted by ISPN-2187. > User-level flags, i.e. FORCE_WRITE_LOCK, should be separated from those that are purely internal, i.e. PUT_FOR_EXTERNAL_READ. > Obviously, user-level flags might be used for internal purpouses, but by making the separation and putting the internal-only flags separately, we should avoid misuse. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2201) Make a distinction between user-level and internal flags

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2201?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2201: ------------------------------------- An interesting conversation related to flags: http://infinispan.markmail.org/thread/5wdhk6suz2aepf62 This should be approached when re-designing the cache API to be closer to JCache and provide specific methods would make the use of certain Flags unneeded: e.g. putNoGet instead of cache.getAdvancedCache().withFlag(IGNORE_RETURN_VALUE) etc. > Make a distinction between user-level and internal flags > -------------------------------------------------------- > > Key: ISPN-2201 > URL: https://issues.jboss.org/browse/ISPN-2201 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > This confusion is highlighted by ISPN-2187. > User-level flags, i.e. FORCE_WRITE_LOCK, should be separated from those that are purely internal, i.e. PUT_FOR_EXTERNAL_READ. > Obviously, user-level flags might be used for internal purpouses, but by making the separation and putting the internal-only flags separately, we should avoid misuse. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2022) Make MarshalledValues immutable

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2022?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2022: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Make MarshalledValues immutable > ------------------------------- > > Key: ISPN-2022 > URL: https://issues.jboss.org/browse/ISPN-2022 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 5.1.4.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > > MarshalledValues are not currently reused, so the containers could be made immutable. Different subtypes would be needed as well, i.e., {{InstanceBaisedMarshalledValue}}, where {{instance}} is {{final}} and {{raw}} then need not be volatile. {{RawBiasedMarshalledValue}}, where {{raw}} is {{final}} and {{instance}} then need not be volatile. {{serialisedSize}} and {{equalityPreferenceForInstance}} would be unnecessary. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2022) Make MarshalledValues immutable

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2022?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2022: -------------------------------- Priority: Minor (was: Major) > Make MarshalledValues immutable > ------------------------------- > > Key: ISPN-2022 > URL: https://issues.jboss.org/browse/ISPN-2022 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 5.1.4.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Fix For: 6.0.0.Final > > > MarshalledValues are not currently reused, so the containers could be made immutable. Different subtypes would be needed as well, i.e., {{InstanceBaisedMarshalledValue}}, where {{instance}} is {{final}} and {{raw}} then need not be volatile. {{RawBiasedMarshalledValue}}, where {{raw}} is {{final}} and {{instance}} then need not be volatile. {{serialisedSize}} and {{equalityPreferenceForInstance}} would be unnecessary. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2022) Make MarshalledValues immutable

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2022?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2022: ------------------------------------- reducing priority as the performance improvement from implementing is this not clear. > Make MarshalledValues immutable > ------------------------------- > > Key: ISPN-2022 > URL: https://issues.jboss.org/browse/ISPN-2022 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 5.1.4.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Fix For: 6.0.0.Final > > > MarshalledValues are not currently reused, so the containers could be made immutable. Different subtypes would be needed as well, i.e., {{InstanceBaisedMarshalledValue}}, where {{instance}} is {{final}} and {{raw}} then need not be volatile. {{RawBiasedMarshalledValue}}, where {{raw}} is {{final}} and {{instance}} then need not be volatile. {{serialisedSize}} and {{equalityPreferenceForInstance}} would be unnecessary. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2938) LuceneCacheLoader to support filtering for preload of the proper type

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2938?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2938: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > LuceneCacheLoader to support filtering for preload of the proper type > --------------------------------------------------------------------- > > Key: ISPN-2938 > URL: https://issues.jboss.org/browse/ISPN-2938 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > We suggest to use 3 caches to store the Lucene index, but the design of the LuceneCacheLoader is assuming it is connected to a single cache which need to load all data on preload=true. > We should add options, or perhaps split in different implementations, to only load the relevant part needed for a specifically configured cache. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-313) Provide an StandaloneJGroupsChannelLookup implementation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-313?page=com.atlassian.jira.plugin.s... ] Bela Ban commented on ISPN-313: ------------------------------- Mircea, I have no idea what you're talking about... > Provide an StandaloneJGroupsChannelLookup implementation > -------------------------------------------------------- > > Key: ISPN-313 > URL: https://issues.jboss.org/browse/ISPN-313 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > StandaloneJGroupsChannelLookup would target environments that are > either standalone or within other app servers that are not JBoss. > It would allow for different Infinispan configurations to use the same > shared transport, reducing network configuration. > Infinispan and StandaloneJGroupsChannelLookup, if you guys create > such a class, have it use the ChannelFactory.createChannel(String > stack_name) method, not the old legacy createMultiplexerChannel method > used by JBC. ChannelFactory.createChannel(String stack_name) will be a > stable API, createMultiplexerChannel(...) may go away in JGroups 3.0. > ChannelFactory.createChannel(String stack_name) lets you get a shared > transport channel if the stack's transport protocol config has the > singleton_name element. > Full thread can be found in forum reference link -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2926) MBean to access cache content

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2926?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2926: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > MBean to access cache content > ----------------------------- > > Key: ISPN-2926 > URL: https://issues.jboss.org/browse/ISPN-2926 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Affects Versions: 5.2.5.Final > Reporter: Edoardo Schepis > Assignee: Manik Surtani > > It would be great to have a tool to access the cache and inspect it. > For troubleshooting, debugging or simply for monitoring, it would be very helpful to show the content of the cache using some kind of tool -- 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, 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 2013