May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2016) Release script should push branch to origin after updating to version+1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2016?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2016: ---------------------------------- Reporter: Tristan Tarrant (was: NadirX) > Release script should push branch to origin after updating to version+1 > ----------------------------------------------------------------------- > > Key: ISPN-2016 > URL: https://issues.jboss.org/browse/ISPN-2016 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 5.1.4.FINAL > Reporter: Tristan Tarrant > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2016) Release script should push branch to origin after updating to version+1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2016?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-2016. ----------------------------------- Resolution: Done > Release script should push branch to origin after updating to version+1 > ----------------------------------------------------------------------- > > Key: ISPN-2016 > URL: https://issues.jboss.org/browse/ISPN-2016 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 5.1.4.FINAL > Reporter: Tristan Tarrant > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1414) Introduce a builder than can create an Infinispan CacheManager

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1414?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-1414: ------------------------------------- Assignee: Tristan Tarrant > Introduce a builder than can create an Infinispan CacheManager > -------------------------------------------------------------- > > Key: ISPN-1414 > URL: https://issues.jboss.org/browse/ISPN-1414 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Pete Muir > Assignee: Tristan Tarrant > > Provide a builder class that allows passing in of SPI instances, rather than doing lookup. This allows for much easier integration, as context from the app server bootstrap can be easily passed in. > For example: > {code} > public class CacheManagerBuilder { > void setClassLoader(ClassLoader cl); > void setTransport(Transport t); > ... > Cache start(); > } > {code} > We would still want to offer a wrapper around this for Java SE users that would expose a create a CacheManager easily. This factory would want to use a CacheManagerBuilder internally to create the cache, but offer a simplified API. You would want to expose the Builder from the factory as well, offering a sensible set of defaults for SE. > This would break backwards compatibility, as doing new EmbeddedCacheManager etc. would no longer be possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1272) Move away from javadoc's aggregate goal

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1272?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-1272. --------------------------------- Resolution: Out of Date > Move away from javadoc's aggregate goal > --------------------------------------- > > Key: ISPN-1272 > URL: https://issues.jboss.org/browse/ISPN-1272 > Project: Infinispan > Issue Type: Enhancement > Components: Build process > Reporter: Galder Zamarreño > Priority: Minor > > We should move away from maven javadoc's aggregate goal because it creates a lot of pains. For starters, it often spawns a separate process, -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-509) Plug listeners via XML

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-509?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-509. -------------------------------- Resolution: Out of Date > 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 was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

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

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-313?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-313. -------------------------------- Resolution: Out of Date > Provide an StandaloneJGroupsChannelLookup implementation > -------------------------------------------------------- > > Key: ISPN-313 > URL: https://issues.jboss.org/browse/ISPN-313 > Project: Infinispan > Issue Type: Feature Request > Components: Core > 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 was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-224) Separate Cache metrics into different subservices in Jopr

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-224?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-224. -------------------------------- Resolution: Out of Date > Separate Cache metrics into different subservices in Jopr > --------------------------------------------------------- > > Key: ISPN-224 > URL: https://issues.jboss.org/browse/ISPN-224 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > The current Jopr plugin shows a Cache with different metrics for each individual metric available in the cache, i.e. cache stores, cache loades, average repl time...etc. > This set up was fine when there was only a handful of metrics, but we after adding all the different managed attributes, we have around ~43 metrics now (some obviously but not always be present, i.e. metrics related to cache stores, deadlock detecting manager...etc), but they still appear but with no metrics at all. > So, as the number of metrics increase, you have a massive list of different values under Cache. > I think it'd be good to separate attributes from different interceptors into different services under Cache, i.e Statistics, Cache Store, Passivation/Activation...etc. > This would make it cleaner to read to the user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-203) REST interface to Infinispan DB

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-203?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-203. -------------------------------- Resolution: Out of Date > REST interface to Infinispan DB > ------------------------------- > > Key: ISPN-203 > URL: https://issues.jboss.org/browse/ISPN-203 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Michael Neale > > As described here: http://www.jboss.org/community/wiki/InfinispanDB > This will build on (or perhaps be built in) the server/rest module - as well as some additions of helper classes to core, and a query language to query module. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-219) More sophisticated discovery of Infinispan instances from JOPR agent

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-219?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-219. -------------------------------- Resolution: Out of Date > More sophisticated discovery of Infinispan instances from JOPR agent > -------------------------------------------------------------------- > > Key: ISPN-219 > URL: https://issues.jboss.org/browse/ISPN-219 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > > Currently, JOPR agent to Infinispan discovery is hardcoded to localhost. This needs further sophistication as indicated in: > Oct 01 10:39:25 <galderz> pilhuhn, one question > Oct 01 10:39:40 <galderz> the <plugin-configuration>, who uses it? > Oct 01 10:40:05 <pilhuhn> that is used to pass in connection properties > Oct 01 10:40:15 <galderz> to who? > Oct 01 10:40:27 <galderz> to the jopr plugin itself? > Oct 01 10:40:42 <pilhuhn> So in the ispn case, the remote jnp url would go int there , yes the plugin itself > Oct 01 10:40:56 <pilhuhn> in the plugin DiscoveryCOmponent you e.g. do > Oct 01 10:41:01 <galderz> right, so that currently is not in use at all, correct? > Oct 01 10:41:07 <pilhuhn> yes > Oct 01 10:41:23 <pilhuhn> Configuration c = resourceDiscoveryContext.getConfiguration(); > Oct 01 10:41:49 <galderz> and what's c:template about? > Oct 01 10:42:04 <pilhuhn> String jnp Url = c.getSimpleProperty("xxx", "jmx:servive......"); with xxx being the property name from the deployment descirptor > Oct 01 10:42:23 <pilhuhn> c:template allows you to provide tempates for the values a user can enter > Oct 01 10:44:12 <pilhuhn> have a look at http://viewvc.rhq-project.org/cgi-bin/viewvc.cgi/rhq/trunk/modules/plugin... > Oct 01 10:44:27 <galderz> so, let me get one thing straight > Oct 01 10:44:43 <galderz> does it make sense to have anything other than localhost in the connectorAddress? > Oct 01 10:44:56 <pilhuhn> There are 2 templates for Twitter and identi.ca that pre-fill the basic connection properties for that plugin to connect to the remote services > Oct 01 10:45:07 <galderz> at the end of the day, can u assume the plugin will always be local to the infinispan instance? > Oct 01 10:45:44 <pilhuhn> This depends on your usage. If you want an agent on all nodes with ispn on, then you can assume localhost > Oct 01 10:46:02 <galderz> well, we have to make a choice > Oct 01 10:46:11 <galderz> or rethink this cos either > Oct 01 10:46:19 <pilhuhn> if you say that you only want one agent for e.g. 10 ispn nodes, then not :-> > Oct 01 10:46:21 <galderz> the rhq-plugin.xml is generated at build it > Oct 01 10:46:59 <galderz> i think that at least > Oct 01 10:47:17 <pilhuhn> A plugin can support manual-add and autodiscovery. Meaning that you can autodiscover ispn on the localhost and stil have a user manually add an instance on a remote host - here he has to provide the correct connection properties > Oct 01 10:47:19 <galderz> that the port and host need to have a ${:} format > Oct 01 10:47:54 <galderz> so that at least, when u start the agent, u can pass (optionally) the location of the infinispan instance > Oct 01 10:48:04 <pilhuhn> That is done via c.getSimpleProperty(propertyName, defaultValue) in the plugin code > Oct 01 10:48:28 <pilhuhn> but yes, you could do it your way too > Oct 01 10:48:48 <galderz> hmmm, not sure if I like default values in code rather than in xml > Oct 01 10:49:05 <galderz> but let me have a think about it > Oct 01 10:49:33 <galderz> so, to get this right > Oct 01 10:49:42 <galderz> how do u call up on the default template? > Oct 01 10:49:58 <galderz> iow, how do I get the default template values? > Oct 01 10:50:25 <pilhuhn> hm. dunno if you can get them. > Oct 01 10:50:40 <pilhuhn> stop > Oct 01 10:50:44 <pilhuhn> let me rephrase > Oct 01 10:51:34 <pilhuhn> IIrc you get this just passed in (the default values you specify in plugin-xml) when you call c.getSimpleProperty(); > Oct 01 10:54:22 <galderz> another question, how can an agent connect to multiple infinispan instances? > Oct 01 10:54:27 <galderz> each in different host and port? > Oct 01 10:55:00 <pilhuhn> yes > Oct 01 10:55:06 <galderz> how? > Oct 01 10:55:19 <pilhuhn> You just need one resource in inventory per ispn instance > Oct 01 10:55:40 <galderz> but the agent, how does it connect to each? > Oct 01 10:55:49 <galderz> the agent has a single connectorAddress > Oct 01 10:56:05 <galderz> so how on earth does it discover several instances in diff nodes? > Oct 01 10:57:22 <pilhuhn> you could in the Discovery component e.g. sweep a whole subnet. Just do a loop for each IP, and if an ispn instance is found, create one DiscoveredResourceDetails object per instance found and return all of those instances > Oct 01 10:58:25 <pilhuhn> or you could, if you have found one, (require one to start at localhost) ask this ispn instance for connection data of other instances in the grid and then create the DiscoveredResourceDetails objects for all of those > Oct 01 10:58:28 <galderz> right, so the connector address is no longer a simple property > Oct 01 10:58:38 <galderz> but makes sense to implement it as a list property > Oct 01 10:58:45 <pilhuhn> no > Oct 01 10:59:13 <pilhuhn> each resource runs in a separate context. per resource we instantiate one IspnComponent class > Oct 01 10:59:32 <pilhuhn> with its own set of values for the plugin config > Oct 01 10:59:49 <galderz> i don't get this > Oct 01 10:59:57 <galderz> the plugin runs in an agent > Oct 01 11:00:01 <galderz> that executes the discoveru > Oct 01 11:00:05 <pilhuhn> yes > Oct 01 11:00:13 <galderz> how do u past a list of ispn isstance urls to that plugin? > Oct 01 11:00:20 <galderz> so that discovery can act on each of them? > Oct 01 11:00:34 <pilhuhn> ah ok, yes that could be done via list > Oct 01 11:00:37 <galderz> i.e. node1:6996, node2:6996...etc > Oct 01 11:00:43 <pilhuhn> But then the user needs to provide the list > Oct 01 11:00:59 <galderz> via a sys property > Oct 01 11:01:14 <pilhuhn> what I was thinking is that you require 1 ispn instance on the host, the agent runs on. > Oct 01 11:01:15 <galderz> it's not uncommon to have properties that act either as single value or lists > Oct 01 11:02:01 <galderz> i..e tcpping host names > Oct 01 11:02:09 <galderz> the possibilities are varios here, i agree > Oct 01 11:02:17 <pilhuhn> ispn should know its topology? > Oct 01 11:02:30 <galderz> ispn knows about the cluster > Oct 01 11:02:37 <galderz> but an agent could be managing diff clusters > Oct 01 11:02:40 <galderz> that don't talk to each other > Oct 01 11:03:02 <galderz> anyway, this requires further thought > Oct 01 11:03:22 <galderz> the easiest way is simply: 1 agent, 1 ispn instance > Oct 01 11:03:38 <pilhuhn> yes > Oct 01 11:04:00 <galderz> i'll suggest diff solutions in the list and see which ones make most sense to implement before GA -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-863) Eviction based on JVM memory utilization

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant closed ISPN-863. -------------------------------- Resolution: Duplicate Issue > Eviction based on JVM memory utilization > ---------------------------------------- > > Key: ISPN-863 > URL: https://issues.jboss.org/browse/ISPN-863 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction > Affects Versions: 4.2.0.Final > Environment: N/A > Reporter: Dave Marion > Labels: eviction, threshold > > Allow user to specify percentage threshold upon which eviction will kick in and begin evicting entries based on the specified strategy. This would allow user to create a cache that will attempt to keep as many entries in memory as possible without having to specify maxEntries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015