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
14 years, 4 months
[Pull Request] Modular Classloading Compatibility
by Jason T. Greene
Available here:
https://github.com/infinispan/infinispan/pull/278
The problem is basically that infinispan currently is using TCCL for all
class loading and resource loading. This has a lot of problems in
modular containers (OSGi, AS7, etc), where you dont have framework
implementation classes on the same classloader as user classes (that is
how they achieve true isolation)
You can read about this in more detail here:
http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
The patch in the pull request is a first step, and should fix many
issues, but it does not address all (there is still a lot of TCCL usage
spread out among cacheloaders and so on), and ultimately it's just a
work around. It should, however, be compatible in any other non-modular
environment.
Really the ultimate solution is to setup a proper demarcation between
what the user is supposed to provide, and what is expected to be bundled
with infinispan. Whenever there is something the user can provide a
class, then the API should accept a classloader to load that class from.
If it's a class that is just internal wiring of infinispan, then
Infinispan's defining classloader should always be used.
The one case I can think of in infnispan where TCCL really makes sense
is in the case of lazy deserialization from an EE application. However
that is only guaranteed to work when you are executing in a context that
has that style of contract (like in an EE component). There are many
other cases though where someone would expect it to work from a non-EE
context (e.g. from a thread pool). What you really want is the caller's
classloader, but that is not cheap to get at, so it's something that
should be supplied as part of the API interaction (in the case where
there is no EE context). Alternatively you can just just require that
folks push/pop TCCL, but users often get this wrong.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 4 months
Re: [infinispan-dev] Possible Bug in Distribution Manager
by Pedro Ruivo
Hi,
Yes I'm using a old version of Infinispan. I will do the update.
Cheers,
Pedro
On 02-06-2011 13:20, infinispan-dev-request(a)lists.jboss.org wrote:
> Hi Pedro, >From your logs it looks like the CH function has duplicate
> addresses in it and that's what's causing some nodes to return the
> same owner twice: 12:04:03,505 TRACE [DistributionManagerImpl] New CH
> is DefaultConsistentHash{addresses ={73=node09-42492,
> 848=node02-34421, 1849=node03-61513, 1850=node03-61513,
> 2093=node10-3814, 2094=node10-3814, 2380=node08-968, 2381=node08-968,
> 3182=node04-53049, 3183=node04-53049, *5868=node07-42120,
> 5869=node07-42120,* 5914=node05-23599, 5915=node05-23599,
> 6410=node01-27066, 6978=node06-24999, 8485=node11-42115,
> 8486=node11-42115}, hash space =10240} How old is your snapshot? Since
> 5.0.0.ALPHA4 the CH interface uses Set<Address>, so duplicates should
> never happen. I think it would be better to use the latest CR release
> instead, 5.0.0.CR3, so you (and us) know exactly what code you're
> using. Cheers Dan I think my changes for ISPN-110 On Wed, Jun 1, 2011
> at 7:49 PM, Pedro Ruivo <pruivo(a)gsd.inesc-id.pt> wrote:
>> > Hi,
>> >
>> > My name is Pedro and I am working in CloudTM project.
>> >
>> > I think that I may have encountered a possible bug in the consistent
>> > hash function.
>> >
>> > I am working on Infinispan 'Pagoa' 5.0.0-SNAPSHOT with JGroups 3.0.0
>> > Alpha1 and I have a total of 100 000 keys distributed by 11 nodes.
>> >
>> > I am using Radargun, that was modified to execute the maximum number of
>> > transactions in a 5 minutes run. All transactions updates at least one
>> > key, ie, I didn't have read-only transactions.
>> >
>> > At the end of the test, ?I am printing all the keys and their location
>> > (keys' owners), and, as you can see for instance here [1], different
>> > nodes have different opinions concerning which replicas are in charge of
>> > storing some keys.
>> >
>> > Note that I didn't change anything in the distribution code and my tests
>> > only update keys, never delete them.
>> >
>> > Part of the log can be found in [2] and the config file is in [3]. In
>> > the log file we have a lot of 'WARN ?[DistLockingInterceptor] xxx entry
>> > commit warmup_key(...) => ?Thread(...)'. Ignore this entries.
>> >
>> > Unfortunately, the problem does not always show up, in my tests this
>> > shows up, say, 5% of the times.
>> >
>> > Did this ever happen to you, or am I hitting a known issue?
>> >
>> > I hope that the information that I am providing can be sufficient to
>> > reproduce the bug, let me know if there is anything else that I can do
>> > to help....
>> >
>> > Cheers
>> > Pedro
>> >
>> > [1] -http://pastebin.com/Pp47ctj9
>> > [2] -http://pastebin.com/tpSXqVmV
>> > [3] -http://pastebin.com/vjVP48L2
>> >
>> > --
>> > INESC-ID Lisboa, sala 511
>> > gsd.inesc-id.pt/~pruivo
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
14 years, 4 months
CacheDelegate
by Pete Muir
Looking at the Class Loading discussion, part of the confusion is that CacheDelegate doesn't do what it says. Delegate is normally used to described the thing that a decorator delegates calls to.
To avoid confusion, I would like to rename CacheDelegate. I would propose it ComposedCache (as it's a Cache impl which is composed of various services which actually implement the Cache itself). Alternatively we could go with CacheImpl.
Any concerns?
14 years, 4 months
Local state transfer before going over network
by Galder Zamarreño
Not sure if the idea has come up but while at GeeCON last week I was discussing to one of the attendees about state transfer improvements in replicated environments:
The idea is that in a replicated environment, if a cache manager shuts down, it would dump its memory contents to a cache store (i.e. a local filesystem) and when it starts up, instead of going over the network to do state transfer, it would load the state from the local filesystem which would be much quicker. Obviously, at times the cache manager would crash or have some failure dumping the memory contents, so in that case it would fallback on state transfer over the network. I think it's an interesting idea since it could reduce the amount of state transfer to be done. It's true though that there're other tricks if you're having issues with state transfer, such as the use of a cluster cache loader.
WDYT?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 4 months
Old JBoss repo in pom.xml
by Galder Zamarreño
Hi all,
So, what's our current approach towards hardcoding maven repositories in the pom.xml files?
Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds:
<repository>
<id>jboss</id>
<url>http://repository.jboss.org/maven2</url>
</repository>
First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories.
Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users
Where do we stand now?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 4 months
