Distribution package restructuring
by Tristan Tarrant
Hi all,
now that the uberjars have been folded into 7.0, we really need to
restructure our zip distributions to accommodate this.
First, the naming. We currently have -bin, -all and -src distributions.
I would like to rename the "-bin" distribution to "-minimal" which would
only include:
- infinispan-embedded
- infinispan-embedded-query
- Javadocs and XSDs for the above
- Example configurations
- Demos for any of the above
Then we would have an -all distribution which would include
- everything from "-minimal"
- additional cachestores (leveldb, remote, rest)
- extra modules (cdi, jcache, tree, spring)
- embedded CLI
- RHQ plugin
I'd also filter the dependencies, e.g. why package the spring deps when
Spring users will be using theirs anyway.
The following is an example layout:
infinispan-X.Y.Z.Final-[minimal|all]
- infinispan-embedded.jar
- infinispan-embedded-query.jar
- README.txt
- README-modules.txt
+ bin
- functions.sh
- ispn-cli.sh
- ispn-cli.bat
+ config
- distributed-udp.xml
- ...
+ schema
- infinispan-config-7.0.xsd
- infinispan-cachestore-jdbc-config-7.0.xsd
- infinispan-cachestore-jpa-config-7.0.xsd
- infinispan-cachestore-leveldb-config-7.0.xsd (all)
- infinispan-cachestore-remote-config-7.0.xsd (all)
- infinispan-cachestore-rest-config-7.0.xsd (all)
+ demos
+ ...
+ doc
+ api
- ...
+ licenses
- ...
+ management
+ rhq-plugin
- infinispan-rhq-plugin.jar
+ modules (all)
+ cli
- infinispan-cli-interpreter.jar
+ jcache
- infinispan-cdi.jar
- infinispan-jcache.jar
- cache-api.jar
+ persistence
+ leveldb
+ remote
+ rest
+ spring
- infinispan-spring.jar
+ tree
- infinispan-tree.jar
11 years, 5 months
JBoss Modules: Unable to upgrade Hibernate Search to Infinispan 7.0.0.Beta2
by Sanne Grinovero
Hi all,
during bootstrap of tests of the Hibernate Search modules on WildFly
8.1 (via Arquillian), when using Infinispan 7.0.0.Beta1 everything
works fine.
When upgrading to latest Beta2 - and no other changes - I get:
Caused by: java.lang.IllegalAccessError: tried to access class
org.hibernate.search.util.impl.ConcurrentReferenceHashMap from class
org.hibernate.search.util.impl.Maps
at org.hibernate.search.util.impl.Maps.createIdentityWeakKeyConcurrentMap(Maps.java:39)
[hibernate-search-engine-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at org.hibernate.search.event.impl.FullTextIndexEventListener.<init>(FullTextIndexEventListener.java:81)
[hibernate-search-orm-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
The code in Maps.java:39 is simply invoking the constructor of the
ConcurrentReferenceHashMap, which is public and located in the same
jar, in the same package.
It seems that the problem is that the infinispan module is now
depending on the infinispan-query module, which is depending on the
hibernate-search module distributed by the Infinispan project.
In other words, I'm having a duplicate of the Hibernate Search jars on
classpath, specifically an older version of what I'm aiming to test.
Ideas?
A workaround I could apply is to not use the modules published by the
Infinispan project and assemble my own modules, removing
infinispan-query and all other stuff I don't need, but I hope for a
better solution.
Ideally like Infinispan uses slot "ispn-7.0", which we download and
use, I think Infinispan should depend (and download) an Hibernate
Search specific slot, rather then re-bundling a specific micro version
without our permission :-P
Modules released by Hibernate Search are currently released using a
slot which matches exactly the release version (so
slot="5.0.0-SNAPSHOT" as built in this test), but I'd be happy to
change that to say "5.0".
Could we try that please?
-- Sanne
11 years, 5 months
origin of cache events in Infinispan
by Mohan Dhawan
Hi All,
Apologies for posting to the dev-list, but no one on the support forum
replied. :(
How does Infinispan determine the origin of the cache events ?
Specifically, when a CacheEntryModified or other notifications are
thrown, then how does Infinispan compute the origin of the event ?
In other words, if one uses ctx.getOrigin() within an interceptor, how
is the origin calculated ? Is is determined using TCP connections at the
receiver node or is it passed along with the message from the sender ?
In case it is the latter, then it is possible for a node to masquerade
as another node.
Also, is event.getGlobalTransaction().getAddress() equivalent to
ctx.getOrigin() ?
Thanks for your help.
Regards,
mohan
11 years, 5 months
Jira change: "New" state for Infinispan issues
by Tristan Tarrant
Hi all,
the Jira workflow for new ISPN issues has been changed to introduce a
"New" state in which all newly created issues will start from. There are
three transitions from this status:
"Hand Over to Development" to switch issue into Open status
"Resolve issue"
"Close issue"
I have attached a diagram of the new workflow.
Old issues will still have the old "Git pull request workflow".
Tristan
11 years, 6 months
Throwing an IllegalStateException subclass when cache/cachemanager stopping/stopped Re: ISPN-4717
by Galder Zamarreño
Hi,
Re: https://issues.jboss.org/browse/ISPN-4717
While investigating [1], I discovered that when clients send operations to terminated/terminating caches, these are not recovered from. To make this easier to handle, I’d like to change cache/cachemanager from throwing IllegalStateException to throwing a new exception that extends IllegalStateException, e.g. CacheStopping/StoppedException or similar. By making it IllegalStateException, it should create minimal disruption for anyone expecting IllegalStateException, although I don’t think this is documented per se. This, together with a HR error code that accompanies it, should make it easier for clients to deal with it and retry.
A new error code will also be added for suspected caches since these are still propagated to clients. Up until know, this has been dealt with by checking the error message, but that could break easily, so again, the later stages of HR 2.0 protocol implementation is good moment for implement these two things.
If anyone has any objections, speak up :)
Cheers,
[1] https://issues.jboss.org/browse/ISPN-4707
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
11 years, 6 months
JGRP-1877
by Bela Ban
Just a quick heads up. I'm currently working on
https://issues.jboss.org/browse/JGRP-1877, which it critical as it may:
- cause RPCs to return prematurely (possibly with a TimeoutException), or
- cause RPCs to blocks for a long time (pick which one is worse :-))
This is due to my misunderstanding of the semantics of
System.nanoTime(), I frequently have code like this, which computes a
future deadline for a timeout:
long wait_time=TimeUnit.NANOSECONDS.convert(timeout,
TimeUnit.MILLISECONDS);
final long target_time=System.nanoTime() + wait_time;
while(wait_time > 0 && !hasResult) { /* Wait for responses: */
wait_time=target_time - System.nanoTime();
if(wait_time > 0) {
try {cond.await(wait_time, TimeUnit.NANOSECONDS);}
catch(Exception e) {}
}
}
if(!hasResult && wait_time <= 0)
throw new TimeoutException();
Variable target_time can possibly become *negative* if nanoTime()
returns a negative value. If so, hasResult is false and wait_time
negative, and therefore a TimeoutException would be thrown !
While I'm at it, I'll also fix my uses of System.currentTimeMillis(),
and replace it with nanoTime(). Our good friend Erik has run into issues
with RPCs (using currentTimeMillis()) hanging forever when their
NTP-based servers adjusted the time .... backwards !
Please be aware of nanoTime() in your own code, e.g.
long t0=nanoTime();
...
long t1=nanoTime();
It is *not* guaranteed that t1 > t0 because of numeric overflow (t0
might be Long.MAX_VALUE-1 and t1 Long.MAX_VALUE +2 !). The only way to
compare them is t1 - t0 > 0 (t1 is more recent) or < 0 t0 is more recent.
Just thought I wanted to pass this on, in case somebody made the same
stupid mistake...
Thanks to David Lloyd for pointing this out !
--
Bela Ban, JGroups lead (http://www.jgroups.org)
11 years, 6 months
