Configuration visitor - Re: [JBoss JIRA] Commented: (ISPN-145) No transport and singleton store enabled should not be allowed
by Vladimir Blagojevic
Hi,
Galder and I talked about this offline. Time to involve you guys!
I just completed visitor pattern for our configuration objects. Visitor
is passed from root of configuration - InfinispanConfiguration object.
InfinispanConfiguration class has a new method:
public void accept(ConfigurationBeanVisitor v)
How do we want to integrate this visitor into existing structure?
1) We add a new factory method to InfinispanConfiguration with
additional ConfigurationBeanVisitor parameter
2) We leave everything as is and if there is a need to pass some visitor
we pass it to InfinispanConfiguration instance directly (from
DefaultCacheManager)
DefaultCacheManager will pass ValidationVisitor to
InfinispanConfiguration that will verify configuration semantically.
Regards,
Vladimir
On 09-09-09 10:19 AM, Galder Zamarreno wrote:
> Good idea :)
>
> On 09/09/2009 04:13 PM, Vladimir Blagojevic wrote:
>> Yeah,
>>
>> I was thinking that we can make a visitor for configuration tree and
>> then you can do verification of any node and other things as well. Use
>> cases will come up in the future for sure.
>>
>> Cheers
>>
>>
>>
>> On 09-09-09 3:29 AM, Galder Zamarreno (JIRA) wrote:
>>> [
>>> https://jira.jboss.org/jira/browse/ISPN-145?page=com.atlassian.jira.plugi...
>>>
>>> ]
>>>
>>> Galder Zamarreno commented on ISPN-145:
>>> ---------------------------------------
>>>
>>> Not sure I understand what you mean by generic though. You mean any
>>> component to have a validation step of some sort?
>>>
>>> Thanks for taking this on :)
>>>
>>>> No transport and singleton store enabled should not be allowed
>>>> --------------------------------------------------------------
>>>>
>>>> Key: ISPN-145
>>>> URL: https://jira.jboss.org/jira/browse/ISPN-145
>>>> Project: Infinispan
>>>> Issue Type: Bug
>>>> Components: Loaders and Stores
>>>> Affects Versions: 4.0.0.ALPHA6
>>>> Reporter: Galder Zamarreno
>>>> Assignee: Vladimir Blagojevic
>>>> Priority: Minor
>>>> Fix For: 4.0.0.CR1
>>>>
>>>>
>>>> Throw configuration exception if singleton store configured without
>>>> transport having been configured.
>>>> It makes no sense to have singleton store enabled when there's no
>>>> transport.
>>
>
12 years, 6 months
ISPN-185: Injecting a running JGroups channel into Infinispan
by Manik Surtani
Regarding ISPN-185 [1] (Need to provide a mechanism in which a JGroups
channel can be passed in), I'd like to discuss a few solutions. I
believe this directly affects the way JBoss AS will use Infinispan, so
it would be good to hear from JBoss AS folk on this subject. :)
Transport [2] is an interface that wraps up the JGroups Channel (among
other things), and the default (only?) implementation so far is the
JGroupsTransport [3]. Now one thing we can do to support channel
injection is to actually support Transport injection. This way a
Transport can be constructed (simple constructor), the JGroups channel
set, and the transport passed in to a GlobalConfiguration instance
(setter TBD), which is then in turn passed to a DefaultCacheManager
constructor [4].
The problem with this approach though, is that it will only work for
programmatic configurations. To support declarative configurations as
well, we'd need to override the relevant DefaultCacheManager
constructors [5] [6] [7] [8] to accept a Transport as well. But this
pollutes the CacheManager API, in my opinion.
So, how important is it that a running channel is used to override
something defined in XML?
Cheers
Manik
[1] https://jira.jboss.org/jira/browse/ISPN-185
[2] http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/remoting/tran...
[3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[4] http://bit.ly/3roPkl
[5] http://bit.ly/vDtwa
[6] http://bit.ly/2FhsUn
[7] http://bit.ly/7YC8d
[8] http://bit.ly/2rgtyP
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 5 months
Re: [infinispan-dev] Hash calculation in DefaultConsistentHash
by Alex Kluge
> Any chance of sharing this work with the rest of Infinispan community
> at some point?
My apologies, The embedded link in the original message did not
propagate through the mailing list. The doc is at
http://www.vizitsolutions.com/ConsistentHashingCaching.html.
There an an implementation of an AddressHash at the bottom, which should
be very close in functionality to the current DefaultConsistentHash. If
it looks correct it can be used directly, or I can tweak it if need be.
The doc will get more interesting when the section on adding a new server
is finished, as you will need it if you go with the virtual nodes.
Alex
--- On Wed, 9/16/09, Galder Zamarreno <galder.zamarreno(a)redhat.com> wrote:
From: Galder Zamarreno <galder.zamarreno(a)redhat.com>
Subject: Re: [infinispan-dev] Hash calculation in DefaultConsistentHash
To: infinispan-dev(a)lists.jboss.org
Date: Wednesday, September 16, 2009, 2:57 AM
Hey Alex,
On 09/14/2009 10:05 PM, Alex Kluge wrote:
> Hi,
>
> I would even make the case that the abs and the remainder operator are unnecessary. I have an version of a consistent hash which is similar to this, and made a few modifications so that my code delivers the same functionality as the current infinispan DefaultConsistentHash. The consistent hash is much more natural if you directly use the hash values. I had meant to contribute this code a while back, but I was simply too busy getting the full project of which this is a part to a testable state to make the infinispan modifications to the code.
>
> These classes are under the examples section in a Consistent hashing and Caching doc I am working on.
>
> This code also supports virtual nodes, but with the settings in the example do not produce any. The builder is there to facilitate the creation of the hash through an XML parser, while keeping the hash itself immutable. These things can all be tuned or changed for infinispan's specific needs.
Any chance of sharing this work with the rest of Infinispan community at
some point?
Regards,
>
> Alex
>
>
> --- On Mon, 9/14/09, Krzysztof Sobolewski<Krzysztof.Sobolewski(a)atm.com.pl> wrote:
>
> From: Krzysztof Sobolewski<Krzysztof.Sobolewski(a)atm.com.pl>
> Subject: [infinispan-dev] Hash calculation in DefaultConsistentHash
> To: "infinispan-dev(a)lists.jboss.org"<infinispan-dev(a)lists.jboss.org>
> Date: Monday, September 14, 2009, 4:25 AM
>
> I took a look at the implementation of DefaultConsistentHash and I was
> wondering: does the key hash value have to be positive? As in:
>
> int hash = Math.abs(key.hashCode());
>
> I can see that the resulting hash is used to pull a tail map of the hash
> space, but there's no reason the SortedMap key has to be positive. I'm
> actually most concerned about the fact that Math.abs(Integer.MIN_VALUE) ==
> Integer.MIN_VALUE so you have at least one negative key anyway :)
> -KS
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
14 years, 6 months
refresh ahead - do we want this?
by Mircea Markus
For example, assume that the expiration time for entries in the cache
is set to 60 seconds and the refresh-ahead factor is set to 0.5. If
the cached object is accessed after 60 seconds, a synchronous read
from the cache store is performed to refresh its value. On the other
hand, if a request is performed for an entry that is more than 30 but
less than 60 seconds old, the current value in the cache is returned
and an asynchronous reload from the cache store is scheduled.
For frequently accessed data, requests won't block waiting for data to
be retrieved from persistent store if data expires.
Wdyt?
Cheers,
Mircea
14 years, 6 months
[ISPN-134] Creating @Jopr* annotations or extending @Managed* ones?
by Galder Zamarreno
Hi,
Heiko, this is FYI too:
Re: https://jira.jboss.org/jira/browse/ISPN-134
I see different ways of doing this. Let's take the DefaultCacheManager
as example. It has 4 @ManagedAttribute methods:
getDefinedCacheCount()
getCreatedCacheCount()
getVersion()
getDefinedCacheNames()
Now, at the jopr level, even these 4 would be treated differently. First
two are measurement metrics, the two below are trait metrics. So, on top
of jopr adding new fields, there's the issue that not all
@ManagedAttribute map to the same thing on the jopr side.
So, my suggestion would be to have some jopr specific annotations that
allow us to differentiate between different jopr types (i.e.
@JoprMetric(dataType="measurement"), @JoprMetric(dataType="trait")) and
where we can add any extra information required by jopr, i.e.
displayName...etc.
I think using this annotations would be cleaner than extending @Managed*
ones. Also, such @Jopr* or annotations would need to live in core/
Heiko, does Jopr have annotations like this already?
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 6 months
Re: [infinispan-dev] Evaluating Infinispan
by Krzysztof Sobolewski
Dnia czwartek 24 wrzesień 2009 o 16:41:25 infinispan-dev-
request(a)lists.jboss.org napisał(a):
> > First, something small: TreeCache.getCache() (I obviously first try
> > to use the
> > tree compatibility layer) returns Cache<K,V>, which is obviously
> > wrong, as the
> > TreeCacheImpl returns Cache (raw type) which is in fact
> > AtomicMapCache<NodeKey,Object> (and really, really in fact it's
> > AtomicMapCache<NodeKey,AtomicMap<?,?>).
>
> Interestingly, this is the first bit of feedback I've got on the
> TreeCache compat layer. Most folks I know are using the Map API
> directly.
That's interesting. I would expect that it would be more popular... But maybe
people that would be porting their code from JBoss Cache are more conservative
about "beta-quality" software :) Or are just happy with what they have now
(for example our JBCache-based module finally works as expected and we're too
afraid to touch it now).
> > As a side note, I don't really like how the getAtomicMap() overrides
> > the V
> > type parameter of Cache. The cache is supposed to store and return
> > V's, but
> > this methods forcibly puts AtomicHashMap as values. I say this will
> > lead to
> > problems. Maybe it's better to make AtomicMapCache<K> (one type
> > parameter)
> > extend Cache<K,AtomicMap<?,?>> (maybe even with optional type
> > parameters for
> > AtomicMap).
>
> Yes, we did consider this, but that would mean that this is all you
> use the cache for. E.g., if someone comes up with a more generic
> Cache<String, Object>, he will be restricted from using AtomicMaps
> with this cache. Perhaps this is a valid restriction, the jury is
> out. What do folks think?
I don't mind that that much... But if I create an AtomicMap for a key and then
forget that it's "special" and try to get a regular V from that key, I will
get a ClassCastException and that's not very good. It's all or nothing or
tricky ;)
> > As another side note, I can see that you're not big fans of
> > generics :)
>
> I actually hate them. :-) I think they are completely broken in the
> way the JDK implements them, and this is why for internal classes and
> APIs, I choose to leave them out completely (InternalCacheEntry, for
> example). I do see their value in public API though.
Yeah, it's a kind of love-hate relationship. I personally prefer to have them
everywhere (and sometimes come up with really bizarre contraptions). At least
one prominent book writer thought once I was an expert on the topic ;)
> > So... Can I ask for an option to not do lock striping... anywhere? :)
>
> You have an option to disable lock striping. See
> Configuration.setUseLockStriping(), or, using XML, see all.xml [1],
> look at the 'lockPerEntry' named cache.
AFAIK this only turns off lock striping in the cache itself, not in the cache
loader. But as I later found out, it's not really relevant because there is no
tree in Infinispan. In JBCache I could run into problems because the cache
loader would try to acquire locks for parent nodes and deadlock with
completely unrelated cache operation whose Fqn's accidentally mapped to the
same locks.
In Infinispan the JDBC cache loader also doesn't use database transactions -
should I be worried about this? :)
>> Well, my biggest gripe with the tree cache layer is that it doesn't
>> like when
>> the node does not exist (for example doing a Cache.put(Fqn, key,
>> value) would
>> create the node in JBCache, but in Infinispan it just throws NPE).
>> That forces
>> me to get/create the node first, and then perform the operation. It
>> doesn't
>> look very atomic. Would batches help here?
>
>This is a bug. TreeCache.put(Fqn, k, v) should behave the same as
>with JBC. Care to file this in JIRA?
Sure...
https://jira.jboss.org/jira/browse/ISPN-199
It turns out that this only affects TreeCache.put(Fqn, Map).
I wonder how much compatible this compatibility layer can/should be. I
don't think a complete, like "bug-for-bug", compatibility is possible and some
of that might be relevant for our internal component. At least until we decide
to port to plain Infinispan, but that will be a completely different, well,
problem.
>> BTW: How do I actually get a reference to AtomicMapCache? I haven't
>> seen any
>> API except for casting...
>
>This AtomicMaps are not meant for public consumption (yet). They are
>internal APIs, although at some point we may want to make them - along
>with DeltaAware and Delta - public. In which case they would need to
>be properly genericized.
>
>Is there any specific reason you need direct access to AtomicMapCaches?
I actually read about it on your blog and assumed that it's a public API :) I
thought I could use it to solve some problems relating to lack of tree
structure (or, more specifically, lack of getChildrenNames()).
-KS
14 years, 6 months
wildcard in cache names
by Mircea Markus
Hi,
While looking into a migration script for coherence I saw that they
allow wildcard as cache names. E.g.
<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>default-replicated</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>VirtualCache</cache-name>
<scheme-name>default-distributed</scheme-name>
</cache-mapping>
So when the code asks for any cache name, they will return the
corresponding mapping:
e.g.
CacheFactory.getCache("SomeCache") would return the "default-
replicated" cache, and CacheFactory.getCache("VirtualCache") would
return the default-distributed cache.
Anyone working with coherence and found this feature useful? I'd love
to see some use cases for this :)
Cheers,
Mircea
14 years, 6 months
