July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2976: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > Log4J dependencies in codebase to be cleaned up > ----------------------------------------------- > > Key: ISPN-2976 > URL: https://issues.jboss.org/browse/ISPN-2976 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > > When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes. > {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly. > {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}. > {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much? -- 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-1402) Limit rate of incoming requests on Hot Rod server

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1402: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Limit rate of incoming requests on Hot Rod server > ------------------------------------------------- > > Key: ISPN-1402 > URL: https://issues.jboss.org/browse/ISPN-1402 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Sanne Grinovero > Priority: Minor > > Like application servers have a way to configure a limit of parallel incoming requests, if a too high number of requests is incoming some of these should be put in a queue, to protect the server performance. -- 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-1491) Provide methods to retrieve the CacheKey parameters

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1491?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1491: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Provide methods to retrieve the CacheKey parameters > --------------------------------------------------- > > Key: ISPN-1491 > URL: https://issues.jboss.org/browse/ISPN-1491 > Project: Infinispan > Issue Type: Enhancement > Components: CDI integration > Reporter: Kevin Pollet > Assignee: Kevin Pollet > > Currently, it's not possible to retrieve the parameter values composing the {{CacheKey}} (generated by JCache interceptors). For that, we could introduce two interfaces. > * {{SimpleCacheKey<T>}} used when only one parameter is used as key. This interface could add the following method {{T getValue()}} > * {{ComposedCacheKey}} used when the key is composed by more than one parameter. This interface could add the following method {{Object[] getValues()}} > Here, we need to ensure that we are compliant with the specification. -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-313?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-313: ------------------------------------ [~belaban] would the new jgroups protocol configuration extension (graphic?) cover this as well? > 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 > Fix For: 6.0.0.Final > > > 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-313) Provide an StandaloneJGroupsChannelLookup implementation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-313?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-313: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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-1401) Provide an easy API to retrieve the total numer of stored entried ( clusterWideSize() )

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1401?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1401: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Provide an easy API to retrieve the total numer of stored entried ( clusterWideSize() ) > --------------------------------------------------------------------------------------- > > Key: ISPN-1401 > URL: https://issues.jboss.org/browse/ISPN-1401 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.1.0.FINAL > Reporter: Sanne Grinovero > Assignee: Manik Surtani > Priority: Minor > > This looks like easy to implement with a distributed executor and a common request. We will also need it as a building block. -- 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-2133) Provide a context for object de-serialization

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2133: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Reporter: Sanne Grinovero > Assignee: Manik Surtani > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- 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-509) Plug listeners via XML

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-509?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-509: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Plug listeners via XML > ---------------------- > > Key: ISPN-509 > URL: https://issues.jboss.org/browse/ISPN-509 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: hotrod > > This would allow Hot Rod servers to be plugged with listeners in an easier way (otherwise you'd have to think of passing some kind of command line parameters with listeners which is not right). > Alternatively, if someone wanted to hook listeners to Hot Rod, they'd to write some code to programatically start a Hot Rod server and associate the listener. -- 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-1147) Programmatically creating cache should be automatically reflected throughout the cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1147?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1147: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Programmatically creating cache should be automatically reflected throughout the cluster > ---------------------------------------------------------------------------------------- > > Key: ISPN-1147 > URL: https://issues.jboss.org/browse/ISPN-1147 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, State transfer > Affects Versions: 4.2.1.FINAL > Reporter: Randall Hauch > Assignee: Manik Surtani > > Consider a symmetric cluster of two nodes (N1 and N2) each with a single cache (C1). Currently, a new cache (C2) must be programmatically created _on all all nodes in the cluster_ (if REPL, or all appropriate nodes if DIST) _before_ that new cache can even be _used_. > Ideally, when a new cache (C2) is created on one node (N1), Infinispan should automatically propagate that creation to the appropriate nodes in the cluster so that the new cache can be used immediately. -- 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-2007) Performance improvements for Infinispan servers

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2007?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2007: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Performance improvements for Infinispan servers > ----------------------------------------------- > > Key: ISPN-2007 > URL: https://issues.jboss.org/browse/ISPN-2007 > Project: Infinispan > Issue Type: Enhancement > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Future improvements for Memcached/HotRod servers: > - Get rid of tuples, they're costly. This would require parameters/header objects to be made mutable. > - In Memcached, Get rid of any String construction and deal directly with byte[]. This would require converting adding validation to String-represented numbers, booleans...etc. This is by far biggest hotspot in our implementation. > - Get rid of any collection (ListBuffer) for parameter parsing in Memcached. -- 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