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
Defining new commands in modules
by Manik Surtani
So this is an extension to the discussion around a GenericCommand that has been going around. IMO a GenericCommand is a big -1 from me for various reasons - the whole purpose of the command pattern is so we have strongly typed and unit testable commands. This will help the ongoing work by Mircea, Sanne and Israel on various modules that need to define custom commands.
I proposed the following solution to Mircea earlier today, I'll repeat here for you guys to discuss. Note that this is a *half baked* solution and needs more thought! :-)
* If a module needs to define custom commands, it should define its own ReplicableCommand implementations in its' own module.
* It should define a sub-interface to Visitor (MyModuleVisitor) with additional methods to handle the new commands
* Interceptors defined in this module should extend CommandInterceptor AND implement MyModuleVisitor
* These new commands can be created directly, or via a new CommandFactory specially for these commands.
Now for the un-finished bits. :)
* How does RemoteCommandFactory instantiate these new commands? The module should have a way of registering additional command IDs with RemoteCommandFactory.fromStream(). See
http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/main/j...
Perhaps RemoteCommandFactory.fromStream() should look up the ID in a map of command creator instances, and each module can register more of these with the RemoteCommandFactory?
* How do interceptors defined in the core module handle commands it isn't aware of? handleDefault()? Or should we define a new handleUnknown() method in Visitor for this case, which would default to a no-op in AbstractVisitor? E.g., in a module-specific command such as MyModuleCommand, I would implement:
class MyModuleCommand implements ReplicableCommand {
public Object acceptVisitor(InvocationContext ctx, Visitor visitor) throws Throwable {
if (Visitor instanceof MyModuleVisitor) {
return ((MyModuleVisitor) visitor).visitMyModuleCommand(ctx, this);
} else {
return visitor.handleUnknown(ctx, this);
}
}
}
Cheers
Manik
PS: There is no JIRA for this. If we like this approach and it works, I suggest we create a JIRA and implement it for 4.2. The impl should be simple once we resolve the outstanding bits.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
12 years, 10 months
ISPN 200
by Israel Lacerra
Manik,
What you mean by:
" * The calling node returns a CacheQuery impl that lazily fetches
and collates results from the cluster." (JIRA)
Is enough if each node returns a list of keys and then, we lazily get the
values using the keys? Or the process has to be more lazy yet?
thanks!
Israel Lacerra
13 years, 2 months
Using Coverity scan?
by Sanne Grinovero
Hello,
Did you consider enabling Infinispan to be monitored by coverity's
code analysis services? They are free for OSS projects, I saw a demo
recently and was quite amazed. It's similar to FindBugs, but not only
about static code checks. They checkout your code from trunk and then
run several analysis on it periodically, one of them is about dynamic
thread behavior to predict deadlocks or missing fences instrumenting
the code, and produce nice public reports; AFAIK you don't need to
setup anything yourself, besides getting in touch to ask for it.
It's only available for C and Java code, and they have an impressive
list of OSS projects in the C world (linux kernel, httpd server,
samba, gnome, GCC, PostgreSQL, ...) but not much on Java.
http://scan.coverity.com/
No, I'm not affiliated :-) Just thinking that it might be useful to
have if it's not too hard to setup.
Cheers,
Sanne
13 years, 4 months
Configuration reference generation - rework
by Vladimir Blagojevic
Hey all,
Manik and I talked privately regarding this topic through https://jira.jboss.org/browse/ISPN-626 and we concluded that we could use some input from people that have used configuration reference markers within Infinispan code etc. Manik basically had a few ideas where he wanted to polish/expand the final look of configuration reference (summed up in ISPN-626) and upon closer inspection I think that we need to rework configuration markers to make things simpler and easier to use.
One of the things I wanted to do is replace javadoc tag @configRef with annotation(s) and use pure comment text of javadoc elements as input for both javadoc and configuration reference. So lets gather some more ideas, and I'll work on this on a side whenever I need the break from hard core stuff :)
Cheers,
Vladimir
--
Vladimir Blagojevic
JBoss Clustering Team
JBoss, by Red Hat
13 years, 6 months
Re: [infinispan-dev] Collocated nodes
by Elias Ross
My original message bounced. In other words, if in practice you want N
copies of something to exist, you can either select N nodes from the
same hash wheel, or create N hash wheels. In this case you'd create at
least two.
On Wed, Sep 22, 2010 at 7:37 AM, Elias Ross <genericelias(a)gmail.com> wrote:
> What about multiple hash wheels? One would exclude those nodes co-located, another would include all nodes.
> -----Original Message-----
> From: Vladimir Blagojevic <vblagoje(a)redhat.com>
> Sender: infinispan-dev-bounces(a)lists.jboss.org
> Date: Wed, 22 Sep 2010 09:44:54
> To: infinispan -Dev List<infinispan-dev(a)lists.jboss.org>
> Reply-To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> Subject: Re: [infinispan-dev] Collocated nodes
>
> The current function that places nodes on a hash wheel is deterministic in case of node joins and crashes/leaves. Even after a node leaves/crashes all surviving nodes in view V' are going be positioned to same hash wheel position as in view V. In another words, all surviving nodes in V' are deterministically placed on the same hash wheel positions absolutely and relatively to each other as they were in view V. The case for join is superfluous to my argument.
>
> I am still learning about this topic but it seems that hash wheel node placing property defined above is necessary for everything to work properly. If so, I find it very hard to devise an algorithm that places nodes on hash wheel based on distance. As soon as one node crashes/leaves positioning surviving nodes in V' to same positions as they were in view V seems impossible since in distance based positioning we need to place nodes in relation to neighbouring nodes.
13 years, 6 months
RPCs for non-existant caches ought not throw exception
by Paul Ferraro
In AS clustering, there are several use cases where a specific cache
instance may not exist (or may not be started) for every member of the
group. Currently, Infinispan treats this as an exception case, and any
cache operation resulting in an RPC will fail. This is problematic for
the following AS use cases:
1. For a given clustering service (e.g. web session, SFSBs, entity
caching) there is a shared cache manager for all applications, while
each application uses its own cache instance. If I have app1 running on
node1 and node2, everything is fine. But if I deploy app2 on node1,
it's membership will include node2 (because of the shared cache manager)
even though there is no cache instance for app2 on node2. Consequently,
the cache instances for app2 will be non-functional until app2 is
deployed on node2.
2. In Hibernate's 2nd level cache, custom cache regions are created on
demand. So, even with a single app running on 2 nodes, the first
request to cache an entity in a custom cache region on node1 will fail,
since the cache corresponding to the region will not exist on node2.
Here's is relevant code in
InboundInvocationHandlerImpl.handle(CacheRpcCommand):
String cacheName = cmd.getCacheName();
ComponentRegistry cr = gcr.getNamedComponentRegistry(cacheName);
long giveupTime = System.currentTimeMillis() + 30000; // arbitraty (?) wait time for caches to start
while (cr == null && System.currentTimeMillis() < giveupTime) {
Thread.sleep(100);
cr = gcr.getNamedComponentRegistry(cacheName);
}
if (cr == null) {
if (log.isDebugEnabled()) log.debug("Cache named {0} does not exist on this cache manager!", cacheName);
return new ExceptionResponse(new NamedCacheNotFoundException(cacheName));
// return RequestIgnoredResponse.INSTANCE; // Suggested fix?
}
For the perspective of the AS, a request for a non-existent cache should
be treated the same way as a request for a stopped cache (that logic
returns RequestIgnoredResponse.INSTANCE).
As Galder pointed out, handling this case via exception was an explicit
workaround for this issue: https://jira.jboss.org/browse/ISPN-447
In the comments for ISPN-447, Manik seemed to suggest that returning an
exception is merely a workaround until this issue is fixed:
https://jira.jboss.org/browse/ISPN-434
As it stands, this is a blocker issue for AS infinispan integration.
Thoughts?
13 years, 6 months
Cassandra CacheStore
by Tristan Tarrant
Dear all,
I have just made the Cassandra CacheStore pass all tests on my environment,
so I've committed everything and enabled the cachestore/cassandra module in
the top pom.xml. Now I'm waiting for Hudson to pick up the change and burn
in flames :)
I will close ISPN-653 now. Any new bugs / features will get their own
issues.
Let me know what you think of the code: style, comments, etc, and whether I
should improve where it is lacking.
Thanks for your support
Tristan
13 years, 6 months
Infinispan 4.1 | Eviction policies for Memcached protocol
by Owen Tran
Hi,
I'm actively trying to replace memcached with Infinispan with the memcached server. Swapping it in with my existing whalin client was very simple, I just had to disable the binary protocol. The problem I'm facing is that evictions based on maxEntries aren't working. Here's the configuration I'm using (btw, I've tried playing with all the parameters by trying different strategies, using DEFAULT threadPolicy, change wakeUpInterval, and maxEntries by powers of 2.
<infinispan>
<global>
<globalJmxStatistics enabled="true"/>
</global>
<default>
<jmxStatistics enabled="true"/>
<eviction wakeUpInterval="500" maxEntries="1024" strategy="LIRS" threadPolicy="PIGGYBACK"/>
<expiration maxIdle="3600000" lifespan="-1"/>
</default>
</infinispan>
Infinispan will remove entries that are expired, but it doesn't seem to evict any items when the cache exceeds the number of maxEntries. I've enabled trace and using JMX to peer into the number of entries, and I easily exceed the maxEntries by running a junit test loading it with 10,000 entries.
I noticed in the DefaultDataContainer it only handles immortalEntries with the bounded concurrency map. Is the memcached server somehow only setting items as mortal entries? If so, this means that the behavior for this memcached is really deficient, since you're bound by memory and can't LRU once maxEntries is reached. The only saving grace are the expiration settings. Is there a suggestion on how I can fix this so I can have the behavior of LRU with eviction?
Thanks,
Owen
Code from DefaultDataContainer...
protected DefaultDataContainer(int concurrencyLevel, int maxEntries, EvictionStrategy strategy, EvictionThreadPolicy policy) {
// translate eviction policy and strategy
switch (policy) {
case PIGGYBACK:
case DEFAULT:
evictionListener = new DefaultEvictionListener();
break;
default:
throw new IllegalArgumentException("No such eviction thread policy " + strategy);
}
Eviction eviction;
switch (strategy) {
case FIFO:
case UNORDERED:
case LRU:
eviction = Eviction.LRU;
break;
case LIRS:
eviction = Eviction.LIRS;
break;
default:
throw new IllegalArgumentException("No such eviction strategy " + strategy);
}
immortalEntries = new BoundedConcurrentHashMap<Object, InternalCacheEntry>(maxEntries, concurrencyLevel, eviction, evictionListener);
mortalEntries = new ConcurrentHashMap<Object, InternalCacheEntry>(64, 0.75f, concurrencyLevel);
entryFactory = new InternalEntryFactory();
}
_______________________________________________________
Owen Tran || VP, Engineering || ezRez Software, Inc.
13 years, 6 months
