5.0.0.Alpha1
by Galder Zamarreño
I'm expecting to release 5.0.0.Alpha1 either tomorrow or Friday. For the people that have tasks assigned for this version (http://is.gd/iMdBD), how does this sound?
Things like distributed executors and query API work will probably be moved to next alpha/beta.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 4 months
Preliminary implementation for ISPN-244 and improvement suggestions.
by Galder Zamarreño
Hi all,
Re: https://jira.jboss.org/browse/ISPN-244
This is trunk now and I've written preliminary documentation for it in http://community.jboss.org/docs/DOC-16198. Have a read through it and let me know what you think.
Now, there's a couple of improvements I'm considering doing even for alpha1:
1. Internally, Infinispan has been mapping Externalizer classes and the types they marshall via @Marshallable interface. I don't think this annotation is really usable as it is for users cos there can be situations where users might not be able to modify the class that they wanna serialize. However, they for sure should be able to modify the Externalizer implementation classes, so I was wondering of converting this annotation into an annotation that an Externalizer class takes and that specifies the type of class that it externalizes and its id. Example:
class Person {
...
}
@Marshalls(typeClass=Person.class, id=768)
class PersonExternalizer Implements Externalizer<Person> {
...
}
This could be a mechanism that could be used in equal manner by both internal and user defined externalizers. We don't wanna be doing annotation scanning, so in the same fashion that for internal externalizers we list the type classes that can be extermalized, this could lead to a user configuration simplification, i.e:
<global>
<serialization>
<externalizers>
<externalizer class="PersonExternalizer" />
</externalizers>
</serialization>
</global>
On startup we'd load the externalizers defined in configuration and search for the @Marshalls annotation which would give us the rest of info which is: typeClass and id. Thoughts?? I think this would make internal and user defined externalizers more homogeneous when it comes to their definition and would simplify configuration.
Chaging @Marshallable to @Marshalls should be easy to do particularly cos this annotation was only used for internal purpouses.
2. The second improvement I had in mind is around programmatic configuration. As you can see in the docu, configuring programmatically user defined externalizers requires quite a bit of code. I was thinking of adding a helper method in global configuration that would hide all of that away. If you take in account my recommendations for the previous point, that would be limited to something along the lines of:
globalCfg.addExternalizer(PersonExternalizer.class);
Where the method would have a signature like: public void addExternalizer(Class<? externds Externalizer> externalizerClass);
We could also have an alternative that uses reflection to load the class and add it: public void addExternalizer(String externalizerClassName);
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 4 months
Re: [infinispan-dev] Clustering quick start guide and sample JGroups files
by Sanne Grinovero
+1 that was my thinking as well, I'd use prefixes soon and remove the old
ones later. Shouldn't be a big problem, hopefully nobody uses his own same
named file and relies on resource loading order.
On 11 Dec 2010 15:02, "Tristan Tarrant" <tristan.tarrant(a)gmail.com> wrote:
Oops, I forgot something else I wanted to say:
aren't those filenames a bit too generic ? Shouldn't we prefix them with
infinispan-* ? I was thinking that in future JBoss AS releases, Infinispan
might be part of the core distribution, but applications may want to use
JGroups by itself and want to use exactly those filenames, but Infinispan's
would be found first in the classpath ... Am I being paranoid ?
Tristan
On Sat, Dec 11, 2010 at 15:58, Tristan Tarrant <tristan.tarrant(a)gmail.com>
wrote:
>
> In the past,...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
13 years, 4 months
Transactions across rehashes
by Vladimir Blagojevic
Hey,
Continuing our conversation related to ISPN-799 that I have to fix soon
:-) In summary, the real reason why tx fails for SingleJoinTest is
actually a tx T being prepared for nodes A,B prior to rehash event
triggered due to join and then committed on nodes A,C after the rehash.
Manik, and I talked briefly on IRC and concluded that it is better to
detect these cases and issue a rollback rather than deal with all the
edge cases arising from handling "tx across rehashes" scenario.
If we do not detect such cases of "tx across rehashes" (which should
occur rarely) the consequence is that some prepared tx will not be
committed and the locks will remain on keys until stale lock cleanup
mechanism or timeout kicks in.
In order to detected and implement handling tx across rehashes I need
your input Mircea. I was looking at recording either a ch used to issue
prepare or list of nodes where tx was prepared. When later, commit is
issued, list of nodes to send commit to is compared to prepared list. If
they are not equal tx is marked for rollback. Same with a hash expect a
different hash might map keys to same nodes. Mircea, can this state
(either ch or list) be stored in global tx. Or you have some better ideas.
Let me know WDYT.
Cheers,
Vladimir
13 years, 4 months
SingleJoinTest#testTransactional failure
by Vladimir Blagojevic
Hi,
SingleJoinTest transactional variant currently fails. But it is destined
to fail as is! Let me explain. We have four nodes {A,B,C,D} and another
node E joins. Just before E joins a tx T is started on one of the
existing nodes with a write to key K. There is essentially a latch in
the prepare of T that is opened only after E succefully joins upon join
rehash. As part of join rehash E needs to invalidate invalid L1 keys and
during that process it tries to lock ..you guessed it key K. Since T
holds a lock on K already eventually E join rehash task times out and as
a result we get a failed test.
I did not write this test and I would not like to change the original
writer's test case intent. What are our options?
Cheers,
Vladimir
13 years, 4 months
Quick start maven archetype (ISPN-817)
by Manik Surtani
Early days yet, but if you feel like playing around with it, do:
$ mvn archetype:create \
-DarchetypeGroupId=org.infinispan \
-DarchetypeArtifactId=sample-project \
-DarchetypeVersion=5.0.0-SNAPSHOT \
-DgroupId=<YOUR_GROUP_ID> \
-DartifactId=<YOUR_ARTIFACT_ID>
This will create a skeleton project all set up to work with Infinispan 5.0.0-SNAPSHOT. Replace 5.0.0-SNAPSHOT to 4.2.0-SNAPSHOT for a 4.2.0-ready project. The skeleton project will include some sample configs as well. Pls have a look and provide feedback!
The sample application is a command-line one. To watch it in action, in your newly created project, do this:
$ mvn install -Prun
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
13 years, 4 months
Tx and rollback
by Vladimir Blagojevic
Hey,
How would I find out why a certain tx is getting marked for rollback? I
am interested in pinpointing source code location in Infinispan code
base where txs are marked for rollback. I need this for ISPN-799.
Cheers,
Vladimir
13 years, 4 months
Make Maven 3.x mandatory?
by Manik Surtani
What do you guys think?
It is a lot faster, downloads dependencies in parallel, and most importantly, the archetype plugin isn't broken!! :-)
Doesn't matter to people who are already using Maven 3.x, but for others, could you pls give it a try and flag any issues you may have? It should be backward compatible.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
13 years, 4 months
