July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-800) Infinispan inside OSGI

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-800: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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-3076) Infinispan should enable use of log4j2

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3076: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.Alpha1) > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.5.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- 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-506) Infinispan should have a notion of comparable dataversion for handling external db updates

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-506?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-506: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Infinispan should have a notion of comparable dataversion for handling external db updates > ------------------------------------------------------------------------------------------ > > Key: ISPN-506 > URL: https://issues.jboss.org/browse/ISPN-506 > Project: Infinispan > Issue Type: Feature Request > Reporter: Max Rydahl Andersen > Assignee: Galder Zamarreño > > As discussed in hotel bar -- 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-2862) Integrate the Self-tuning Data Placement from CloudTM into Infinispan

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2862?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2862: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > Integrate the Self-tuning Data Placement from CloudTM into Infinispan > --------------------------------------------------------------------- > > Key: ISPN-2862 > URL: https://issues.jboss.org/browse/ISPN-2862 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Attachments: autoplacer.pdf > > > With the same goal as L1 Cache, it applies a different technique to reduce the communication overhead. The self-tunning data placement detects which are the keys most accessed by each node, modifies the ConsistentHash and triggers the State Transfer in order to move the keys for that nodes. > The main difference for L1 Cache is the fact that L1 creates a new copy of the <key,value> in the requestor node, that needs to be invalidated later. The Data Placement, really moves the <key,value> to that requestor. > Both techniques can be enabled at the same time. > This module depends of ISPN-2861, namely the top-key module. -- 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-2810) In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2810?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2810: -------------------------------- Fix Version/s: 6.0.0.Final > In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0 > -------------------------------------------------------------------------------- > > Key: ISPN-2810 > URL: https://issues.jboss.org/browse/ISPN-2810 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 6.0.0.Final > > > Contrary to what ISPN-732 says, timeToLiveSeconds=0 and maxIdleTimeSeconds=0 are now treated correctly by the server and the entry is stored in the cache with the default lifespan/maxIdle. > But if the user PUTs or POSTs an entry and doesn't specify timeToLiveSeconds=0 and maxIdleTimeSeconds=0 explicitly, the entries are stored with infinite lifespan/maxIdle. -- 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-1450) Improve performance of tree cache writes in nodes with a lot of data

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1450?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1450: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Improve performance of tree cache writes in nodes with a lot of data > -------------------------------------------------------------------- > > Key: ISPN-1450 > URL: https://issues.jboss.org/browse/ISPN-1450 > Project: Infinispan > Issue Type: Enhancement > Components: Tree API > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Look into speeding up tree cache performance when it comes to storing large amount of key/value pairs in a single node. -- 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-1834) Improve the way custom objects are injected into ExtendedModuleCommandFactory impls

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1834?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1834: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Improve the way custom objects are injected into ExtendedModuleCommandFactory impls > ----------------------------------------------------------------------------------- > > Key: ISPN-1834 > URL: https://issues.jboss.org/browse/ISPN-1834 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Manik Surtani > > Retrieving the ExtendedModuleCommandFactory associated with a cache manager is a PITA right now, you have to do: > {code}GlobalComponentRegistry globalCr = cache.getComponentRegistry().getGlobalComponentRegistry(); > // TODO: This is a hack, make it easier to retrieve in Infinispan! > return (CacheCommandFactory) ((Map) globalCr.getComponent("org.infinispan.modules.command.factories")) > .values().iterator().next(); > {code} > Provide a cleaner way of initialising cache command factories for custom objects that the factory can plug into the remote commands. Example: evict all in 2LC where commands need to know the cache region (a Hibernate construct) on which to operate on. -- 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-2810) In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2810?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2810: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0 > -------------------------------------------------------------------------------- > > Key: ISPN-2810 > URL: https://issues.jboss.org/browse/ISPN-2810 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > > Contrary to what ISPN-732 says, timeToLiveSeconds=0 and maxIdleTimeSeconds=0 are now treated correctly by the server and the entry is stored in the cache with the default lifespan/maxIdle. > But if the user PUTs or POSTs an entry and doesn't specify timeToLiveSeconds=0 and maxIdleTimeSeconds=0 explicitly, the entries are stored with infinite lifespan/maxIdle. -- 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-2266) Migrate deprecated configuration API in tests

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2266?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2266: -------------------------------- Fix Version/s: 6.0.0.Final > Migrate deprecated configuration API in tests > --------------------------------------------- > > Key: ISPN-2266 > URL: https://issues.jboss.org/browse/ISPN-2266 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 5.2.0.Alpha3 > Reporter: Thomas Fromm > Assignee: Navin Surtani > Fix For: 6.0.0.Final > > > Migrate tests to current configuration API -- 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-2275) Migrate Cassandra Cache Store to CQL3

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2275?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2275: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Migrate Cassandra Cache Store to CQL3 > ------------------------------------- > > Key: ISPN-2275 > URL: https://issues.jboss.org/browse/ISPN-2275 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Affects Versions: 5.2.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > -- 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