July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3193) Capture time budgeting information

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3193?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3193: -------------------------------- Priority: Minor (was: Major) > Capture time budgeting information > ---------------------------------- > > Key: ISPN-3193 > URL: https://issues.jboss.org/browse/ISPN-3193 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Minor > Labels: diagnostics, performance > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > Should be most recent timing for each major subsystem for each type of call. E.g., > PUT: 10ms (locking), 10ms (datacontainer), 20ms (RPC), 30ms (CacheStore). > GET: 0ms (locking), 5ms (datacontainer), 0ms (RPC), 10ms (CacheStore). > etc. > Could be implemented as a simple ringbuffer, in a specific component (TimeBudgetMonitor?) just storing the most recent N calls and that's it. Cheap to capture, cheap to store. > This data could then be made available via a JMX operation on TimeBudgetMonitor. This is extremely valuable for tuning and debugging perf issues. -- 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-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2826: -------------------------------- Priority: Minor (was: Major) > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Ray Tsang > Assignee: Adrian Nistor > Priority: Minor > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- 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-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2826: -------------------------------- Fix Version/s: (was: 6.0.0.Final) (was: 6.0.0.Beta1) > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Ray Tsang > Assignee: Adrian Nistor > Priority: Minor > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- 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-2399) CacheManager.startCaches very slow when multiple caches are passed in

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2399?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2399: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > CacheManager.startCaches very slow when multiple caches are passed in > --------------------------------------------------------------------- > > Key: ISPN-2399 > URL: https://issues.jboss.org/browse/ISPN-2399 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.0.Beta1 > Reporter: Mircea Markus > Assignee: Mircea Markus > > the TransactionsSpanningReplicatedCachesTest uses the following code to start multiple caches: > {code:java} > cm1.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME); > cm2.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME); > waitForClusterToForm("c1", "c2", "cache1", "cache2"); > {code} > On my machine(MBP) this executes in 12 mins.The functionally equivalent below executes in 15 secs: > {code:java} > private void startAllCaches() { > startCache("c1"); > startCache("c2"); > startCache("cache1"); > startCache("cache2"); > startCache(CacheContainer.DEFAULT_CACHE_NAME); > } > private void startCache(String c1) { > cm1.getCache(c1); > cm2.getCache(c1); > waitForClusterToForm(c1); > } > {code} > We need to analyse why this takes so long and also updated the test to use the CacheManagers.startCaches.. -- 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-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2826: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Ray Tsang > Assignee: Adrian Nistor > Fix For: 6.0.0.Final > > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- 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-1413) CacheManager per application to provide "Session style" construct

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1413?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1413 at 7/2/13 6:53 AM: ------------------------------------------------------------- We currently have: {code:java} Cache appCache = cacheManager.getCache("appCache").getAdvancedCache().withClassLoader(appClassLoader); //use the appCache instance which uses the specified class appClassLoader for marshalling, class loading etc. {code} Doesn't this cover the use case for this JIRA? was (Author: mircea.markus): We currently have: {code:java} Cache appCache = cacheManager.getCache("appCache").getAdvancedCache().withClassLoader(appClassLoader); //use the appCache instance which uses the specified class appClassLoader for marshalling, class loading etc. {code} Doesn't this cover the scenario for this JIRA? > CacheManager per application to provide "Session style" construct > ----------------------------------------------------------------- > > Key: ISPN-1413 > URL: https://issues.jboss.org/browse/ISPN-1413 > Project: Infinispan > Issue Type: Feature Request > Reporter: Pete Muir > Assignee: Manik Surtani > Attachments: Cache Manager per Application.gliffy, Cache Manager per Application.png > > > This solves a problem with classloading, as Infinispan will know exactly what classloader to use for a cache manager and any deserialized cached objects, events etc. > However, it does require support for asymmetric clusters. > Open issues are: > * how do we handle EARs > * how do we handle shared 2nd level caches > * needs support for asymmetric clusters > * needs to mux JGroups channels > * needs consideration of how to handle shared thread pools -- 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-1413) CacheManager per application to provide "Session style" construct

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1413?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1413: ------------------------------------- We currently have: {code:java} Cache appCache = cacheManager.getCache("appCache").getAdvancedCache().withClassLoader(appClassLoader); //use the appCache instance which uses the specified class appClassLoader for marshalling, class loading etc. {code} Doesn't this cover the scenario for this JIRA? > CacheManager per application to provide "Session style" construct > ----------------------------------------------------------------- > > Key: ISPN-1413 > URL: https://issues.jboss.org/browse/ISPN-1413 > Project: Infinispan > Issue Type: Feature Request > Reporter: Pete Muir > Assignee: Manik Surtani > Attachments: Cache Manager per Application.gliffy, Cache Manager per Application.png > > > This solves a problem with classloading, as Infinispan will know exactly what classloader to use for a cache manager and any deserialized cached objects, events etc. > However, it does require support for asymmetric clusters. > Open issues are: > * how do we handle EARs > * how do we handle shared 2nd level caches > * needs support for asymmetric clusters > * needs to mux JGroups channels > * needs consideration of how to handle shared thread pools -- 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-1413) CacheManager per application to provide "Session style" construct

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1413?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1413: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > CacheManager per application to provide "Session style" construct > ----------------------------------------------------------------- > > Key: ISPN-1413 > URL: https://issues.jboss.org/browse/ISPN-1413 > Project: Infinispan > Issue Type: Feature Request > Reporter: Pete Muir > Assignee: Manik Surtani > Attachments: Cache Manager per Application.gliffy, Cache Manager per Application.png > > > This solves a problem with classloading, as Infinispan will know exactly what classloader to use for a cache manager and any deserialized cached objects, events etc. > However, it does require support for asymmetric clusters. > Open issues are: > * how do we handle EARs > * how do we handle shared 2nd level caches > * needs support for asymmetric clusters > * needs to mux JGroups channels > * needs consideration of how to handle shared thread pools -- 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-800) Infinispan inside OSGI

by Luca Stancapiano (JIRA)

[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ] Luca Stancapiano commented on ISPN-800: --------------------------------------- Hi Daniel...no news from RHQ.... could someone contact with voice them? > Infinispan inside OSGI > ---------------------- > > Key: ISPN-800 > URL: https://issues.jboss.org/browse/ISPN-800 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Reporter: Luca Stancapiano > Assignee: Galder Zamarreño > > We need to import infinispan inside a OSGI repository. Tests are made with Felix. > I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan > I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI. > Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc) > Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles: > jboss transaction api 1.0.1.GA > We patched it. There is a new OSGI version here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... ) > jgroups 2.10.1.GA > (it's a osgi bundle since the 3.x version) > river 1.2.3.GA > (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/river/pom.xml ) > marshalling-api 1.2.3.GA > (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/api/pom.xml ) > jboss logging spi 2.0.5.GA > (added a jira issue in JBLOGGING-51 . It could be fixed in the 2.2.0.CR2 version. Fixed in the 3.x version) > rhq plugin annotations 1.4.0.B01 > (opened a feature request in https://bugzilla.redhat.com/show_bug.cgi?id=657754 ) > i18nlog 1.0.9 > (sent a patch in https://sourceforge.net/projects/i18nlog . It could become a OSGI bundle in the 1.0.10 version. Waiting for a response. Fixed in 1.15) > log4j 1.2.16 > (that's ok...it is a osgi bundle ;)) > jcip-annotations 1.0 > (I sent a patch via email to brian(a)briangoetz.com and a post in http://tembrel.blogspot.com. Sent the patch in concurrency-interest(a)cs.oswego.edu too. They responded to me. There is a OSGI version with a different artifact name. I changed the dependency in the pom.xml of the parent project) > We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that: > 1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan. > 2 - it does not fail due to the dependency that is not really essential. -- 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-2317) Distributed Callable with automatic filled keys in environment where current node = owner

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-2317?page=com.atlassian.jira.plugin.... ] Thomas Fromm commented on ISPN-2317: ------------------------------------ "where the current node is the primary owner" should be the text in the ticket. So with this DistCallable I've a workaround to process every entry once. But I need to walk through every entry and check if the current node is the primary owner. However, I think this can also be solved when misuse M/R for that. Lets close it. > Distributed Callable with automatic filled keys in environment where current node = owner > ----------------------------------------------------------------------------------------- > > Key: ISPN-2317 > URL: https://issues.jboss.org/browse/ISPN-2317 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.1.7.Final > Reporter: Thomas Fromm > Assignee: Vladimir Blagojevic > > In a distributed cache I need to process every key one time. My solution is ATM to create a distributed call and on every node walk through the keyset of the cache and process every node, where the current node is the owner. > This solution works, but is not really nice. > I'd like to have a specific Distributed callable for this or an flag/option to enable that the keys where the current node is owner are used at setEnvironment(...). -- 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