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.
>>
>
13 years, 2 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
13 years, 6 months
Comments on tutorials etc.
by Pete Muir
As part of getting up to speed with infinispan, I've been running through the docs and tutorials. Some thoughts
1) http://www.jboss.org/infinispan/downloads.html
One thing that is always annoying is having to configure the jboss repo. I suggest adding this snippet to the above page for people to copy, which can be pasted into either the pom, or into settings.xml, and is self contained.
<profiles>
<profile>
<id>jboss-public-repository</id>
<activation>
<property>
<name>jboss-public-repository</name>
<value>!false</value>
</property>
</activation>
<repositories>
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
2) http://www.jboss.org/infinispan/downloads.html
Suggest adding two code snippet for the dependency too:
a)
<properties>
<infinispan.version>X.Y.Z.Q</infinispan.version>
</properties>
b)
<dependencies>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>${infinispan.version}</version>
</dependency>
</dependencies>
3) http://community.jboss.org/wiki/5minutetutorialonInfinispan
Cache cache = manager.getCache();
I get a warning with this line in Eclipse, as Cache should be a parameterized type. Doesn't break stuff, but doesn't look good that we advise people to write incorrect code.
4) http://community.jboss.org/wiki/5minutetutorialonInfinispan
To make this totally fool proof, might want to indicate how people can run this, e.g. in a main method on a class. This also really highlights how "lightweight" this stuff is (no need for a big server etc.)
5) http://community.jboss.org/wiki/5minutetutorialonInfinispan
For the expiration, might want to adjust the values a bit. 60s is a long time to wait, and also setting the expiration to 60s, and the thread sleep to 60s is risking the assertion failing (it did for me). I would suggest something more like 5s expiration, 10s sleep.
6) http://community.jboss.org/wiki/InstallingInfinispantutorialenvironment
This information is really useful, and I would suggest splitting out the groovy bit and then adding a link from the 5 min tutoiral
7) http://community.jboss.org/wiki/InstallingInfinispantutorialenvironment
Some of the instructions on this page could be clearer if they all built as code blocks. For example, following the groovy ones, I struggled reading the first paragraph, it would have been helpful to split this up and provide code snippets to use like:
$> cp $INFINISPAN_HOME/infinispan-core.jar ~/.groovy/lib/
etc.
8) http://community.jboss.org/wiki/InstallingInfinispantutorialenvironment
The location of infinispan-core jars and dependencies has changed from $INFNISPAN_HOME/modules/core to $INIFINISPAN_HOME, the tutorial needs updating
9) http://community.jboss.org/wiki/Infinispaninteractivetutorial
When doing the below line, I get an error:
And now, create a cache manager indicating the file with the cache definitions.
groovy:000> manager = new DefaultCacheManager("sample-configurations.xml"
)
===> org.infinispan.manager.DefaultCacheManager@19cc1b@Address:
null
oovy:000> manager = new DefaultCacheManager("/Users/pmuir/Downloads/sample-configurations.xml")
ERROR java.io.IOException:
null
at org.infinispan.config.InfinispanConfiguration.newInfinispanConfiguration (InfinispanConfiguration.java:264)
at org.infinispan.config.InfinispanConfiguration.newInfinispanConfiguration (InfinispanConfiguration.java:282)
at org.infinispan.config.InfinispanConfiguration.newInfinispanConfiguration (InfinispanConfiguration.java:136)
at org.infinispan.manager.DefaultCacheManager.<init> (DefaultCacheManager.java:243)
at org.infinispan.manager.DefaultCacheManager.<init> (DefaultCacheManager.java:229)
at groovysh_evaluate.run (groovysh_evaluate:4)
and I don't know how to get past it, so I stopped this tutorial here.
10) http://community.jboss.org/wiki/InfinispanInteractiveTutorialwithScala
Could do with some comments explaining what each line is doing, some of the code isn't self describing
e.g.
what does me entering val defaultCache = manager.getCache[String, String]() actually achieve?
11) http://community.jboss.org/wiki/InfinispanInteractiveTutorialwithScala
It might be neat to split up input and output e.g. into different snippets - make it easier to read
12) http://community.jboss.org/wiki/InfinispanInteractiveTutorialwithScala
For "Cache with Transaction Management" I was not seeing TX semantics being obeyed, I saw the size increment as a added key-value pairs
13) http://community.jboss.org/wiki/SettingupanInfinispanCluster
When I do gc.setTransportClass(JGroupsTransport.class.getName()); and import JGroupsTransport I get two options, one from Infinispan and one from JGroups, tutorial should saw which to import.
14) http://community.jboss.org/wiki/SettingupanInfinispanCluster
The CacheManager is deprecated, I guess these needs updating to 4.2 API?
15) http://community.jboss.org/wiki/SettingupanInfinispanCluster
I would suggest adding some instructions about how to do a simple test to see the cluster working, atm the tutorial seems to end in middle of something. There are hints in the comment, but nothing concrete
13 years, 10 months
Introducing JGroups scopes
by Vladimir Blagojevic
Hey,
JGroups scopes [1] have been implemented for a while now and we should
think about using them in Infinispan. I looked around a bit to see how
we can use scope and satisfy requirements Manik outlined [2]. I think a
good idea would be to introduce scope method in InvocationContext? We
can start by implementing scope to return hash of cache name where
invocation originated and subsequently refine this scope by adding
GlobalTransaction and so on. Users, if they really need to scope their
calls could do so by attaching additional markers to InvocationContext
or smth similar.
WDYT?
[1]https://issues.jboss.org/browse/JGRP-822
[2]https://issues.jboss.org/browse/ISPN-3
13 years, 10 months
DistributionManagerImpl.rehash()
by Bela Ban
I see that this method calls MembershipArithmetic.getMemberJoined(),
which returns the newly joined member. This is done by removing the
existing members from the new members, and returning the first element
of the remaining list.
However, when we have view V1={A,B} and V2={A,B,C,D}, then the method
getMemberJoined() returns C, but skips D.
It seems to me that this logic is based on the assumption that JGroups
only ever joins and removes 1 member at a time, but this is not correct,
as JGroups can join multiple new members, or remove multiple members at
once, too.
Can you guys take a look ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
13 years, 10 months
Rehashing and ongoing transactions
by Manik Surtani
Guys,
I see this in the code base:
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
which has come in as a part of this commit:
https://github.com/infinispan/infinispan/commit/e85204dc34e058c256846699a...
This is no good, since throwing an IllegalStateException *after* a transaction has prepared and is attempting to commit will leave the transaction in an inconsistent state. This is why I see heuristic exceptions when trying to stress a lot of transactions while having nodes join/leave.
A few points:
1) Mircea, are you aware of this, and is this a part of the transaction refactoring you are working on?
2) If not, it probably should be. ;)
3) Vladimir, why is this check necessary in the first place? If prepares have happened on nodes A and B, and the commit should now go to nodes B and C due to a rehash, can't we send the commit to a union of A, B and C, and let the nodes that don't care about the tx anymore just ignore the commit?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
13 years, 10 months
configuring the consistent hash
by Mircea Markus
Hi,
While extending the ConsistentHash I needed to pass some config params to my custom implementation - this is not currently supported
I think adding this functionality would be useful and consistent with other extension points, e.g. cacheLoaders.
What I have in mind is something like:
<hash ...>
<consistentHashFunction class="...">
<properties>
</properties>
</consistentHashFunction>
</hash>
Wdyt?
Cheers,
Mircea
13 years, 10 months
ISPN-863 proposal
by Vladimir Blagojevic
Dave,
I applaud you for this effort and your implementation and wiki are
indeed admirable as you have followed the goals outlined in this JIRA.
However, now that I have had an opportunity to look at the final
solution I have one concern. We went through a great lengths to design a
container that has a low lock contention [1] while maintaining high
precision of a sophisticated eviction algorithm. Goals outlined in this
JIRA have lead you in a direction to redesign the original proposal. I
was wondering if it is possible to use your MemoryMonitor to make a
decision whether or not to grow BCHM rather than to check if eviction
should be done upon each put invocation? Currently we preset the size of
BCHM and we never grow it (i.e. Segment#rehash is never invoked). Maybe
this is a place where MemoryMonitor comes as a natural fit. We can keep
the current design as outlined in [1] while reaping the benefits of a
memory bound resizeable container.
WDYT?
Regards,
Vladimir
[1]
http://infinispan.blogspot.com/2010/03/infinispan-eviction-batching-updat...
Dave said:
It took me some time to figure out how to use Git and add some more
tests. I have pushed my changes to a topic branch located at
https://github.com/dlmarion/infinispan/tree/ISPN-863-master.
Please let me know if you have any questions or concerns. I have put up
some documentation at
https://github.com/dlmarion/infinispan/wiki/ISPN-863-Implementation
-- Dave Marion
13 years, 10 months
ISPN-863
by david marion
Manik,
I am on the list. I will start getting my dev environment setup according to instructions on site.
Dave Marion
13 years, 10 months
4.2.1.FINAL
by Manik Surtani
Hi all
Are we ready for this? There is one open issue assigned to me (ISPN-896) which I will look at tomorrow, and a few others assigned to Mircea and Galder. WDYT about a release on Friday? Any more important feedback from 4.2.1.CR1 that needs addressing?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
13 years, 11 months
