ISPN-1415 and 5.0.2.FINAL

[craigching]

Hi,

We are using Infinispan 5.0.1.FINAL (well, upgrading to 5.0.1.FINAL from 4.1.0.FINAL)  and are being bitten by ISPN-1415 (timeouts on replicated cache).  That issue says that it will be fixed in 5.0.2.FINAL, but I don't see the commit on the 5.0.x branch.  Maybe I'm not understading the process, can someone confirm that ISPN-1415 is fixed on the 5.0.x branch?  I believe the commit to master was 80d97d5.

I'd try to use master, but we're in an OSGi environment and it seems every release of Infinispan makes it harder and harder to use in OSGi.  Are there any plans to formally support OSGi?  Maybe I should have asked that as a separate question ;-)

Thanks for any help!

Cheers,
Craig

[sannegrinovero]

Hi Craig,

regarding the OSGi problems, support was contributed but we have no regression tests; could you open issues on JIRA regarding problems, and ideally if you could contribute some tests we will be able to make sure that support stays and won't fade away while making other changes.

Dan is checking if the fix was not backported, and see if he should do so.

[dan.berindei]

I checked the history and indeed I didn't backport the fix. In fact I'm pretty sure that I left the 5.0.2.FINAL fix version in there by mistake, because the replicated-mode state transfer in 5.0.1 used a completely different mechanism compared to 5.1.0, so fixing it is not going bo be a "backport" by any definition. I'll remove the 5.0.2.FINAL fix version from the ISPN-1415 page to stop misleading people.

As Sanne said, please open issues for the OSGi problems you're seeing, ideally with test cases, and we'll try to fix them.

[craigching]

Hmmm, well that issue perfectly summed up the problem I was having.  In 4.0.1.FINAL we didn't get the warning about assymetric cluster/cache configuration and it made sense, so I changed to using EmbeddedCacheManager.startCaches() and immediately ran into timeouts when the second cluster member connected.  So, not the same problem?

As for OSGi, I wish it were as simple as adding test cases.  I mean, test cases are one thing you could do to help, but that would mean during testing instantiating an OSGi framework.  Something like PAX-Exam could help, but it means a commitment on the development side to maintain them.

My advice, if you want to support OSGi, get someone who understands OSGi on your development team.  OSGi support has to start with how you divide out your APIs.  For instance, one of the problems I ran into with 5.1.0 is that you have the same packages with classes in them in two different jars (I think it was infinispan-core and infinispan-common, something like that, I think there were even duplicate classes), there is a restriction on OSGi bundles that only one bundle can export a package.

Another problem I had was when you included the JBoss module stuff, you assumed that all your classes come from the same class loader.  In 4.1.0, you didn't have this restriction so I was able to create separate bundles of each jar file that infinispan depends on.  When you changed to JBoss modules, I had to change to creating one big super-bundle that has everything in it.  That isn't very modular.

It's kind of at the point where we're probably going to have to keep infinispan in it's own JVM and interact with it via hotrod or REST or just jettison the idea of Infinispan in our environment.  Please don't take that as a threat or anything, it's just our reality with OSGi ;-)

If there is anything I can do to help, I'm glad to.  But I think OSGi is bigger than just having some tests in your test suite.

As for what I'm going to have to do at this point, this is a pretty serious bug for replicated caches on 5.0.x, but I'm not sure it's in our best interest to look at it.  We're probably going to have to revert to 4.0.1 and work with 5.1.0 going forward.  Of course I'll raise issues as I run into them and help out with what I can ;-)

Thanks for looking into this, I appreciate the help!

[sannegrinovero]

Hi Craig,

I agree this very likely needs some commitment from someone understanding OSGI. While Red Hat does employ some experts in the area, they are quite busy and not necessarily familiar with Infinispan.

This is an open source project, and since you're using it and having a good understanding of the issues you're facing, I think that if you would be willing to take this responsibility, you would be the best choice for this. That would be awesome, and good benefits for yourself and your company as you could implement the interfaces which suit you most.

If you have any idea on how to validate correctness in any way we could automate in the testsuite, please just send a pull request: we'll integrate it, that will make regressions unlikely.

Please note that the following was committed yesterday in master:

b9617dd Disable OSGi bundles because of a bug in the felix maven-bundle-plugin which incorporates classes in case of split packages

[craigching]

Hi Sanne,

Don't get me wrong, I understand that this is an open source project and I've given it a lot of thought about how I could help with respect to OSGi and Infinispan.  Let me work through bundling 5.1.0 and maybe I can open some issues that might help move the conversation forward.  It would be exceedlingly difficult for me to just contribute OSGi expertise, I think I'd have to become much more involved in the deeper issues of developing a grid.  Not that that wouldn't be extremely interesting to me, I'm just not sure I have time for it ;-)

About this:

Sanne Grinovero wrote:

Please note that the following was committed yesterday in master:

b9617dd Disable OSGi bundles because of a bug in the felix maven-bundle-plugin which incorporates classes in case of split packages

Is there an issue for this that might explain in more detail what the problem was?  You want to avoid split packages, regardless of whether you're OSGi or J2SE (or JEE).

[nadirx]

Craig, this is being tracked in https://issues.jboss.org/browse/ISPN-1537 and the linked https://issues.apache.org/jira/browse/FELIX-3238

If you can help, please do

And, yes, avoiding split packages is something we would like to do, but it's not going to happen in the 5.x cycle since it requires API changes which we are not willing to perform in a minor release.

[sannegrinovero]

No worries, I understand I've been in the community for a long time; I just want to make sure you know it's not hard to contribute, and you really are in the best position to improve this as you can actually try it out.

The issue is tracked by https://issues.jboss.org/browse/ISPN-1537

[craigching]

Tristan Tarrant wrote:

Craig, this is being tracked in https://issues.jboss.org/browse/ISPN-1537 and the linked https://issues.apache.org/jira/browse/FELIX-3238

If you can help, please do

And, yes, avoiding split packages is something we would like to do, but it's not going to happen in the 5.x cycle since it requires API changes which we are not willing to perform in a minor release.

The maven bundle plugin issue is interesting.  I'm not sure it's a legitimate problem that it can fix, it comes down to the fundamentals of OSGi, you simply can't export a package from two different bundles (versioning aside).  The only ways to fix it is to get rid of the split package or combine the two jars into one bundle.

[sannegrinovero]

Craig, please have a look into those packages, and try figure out how we should define the API; I have no clue ;-)

especially if this can be done in some backwards compatible way, send a proposal to the developer mailing list or a pull request if it doesn't require discussion.

[craigching]

I'll see what I can do.

[nadirx]

Actually the OSGi R4 specification allows exactly for this (as many bundles in Eclipse were broken in this respect to begin with). Look at the chapter "Requiring Bundles", which I paste below for convenience:

A given package may be available from more than one of the required bun-
dles. Such packages are named split packages because they derive their con-
tents from different bundles. If these different bundles provide the same
classes unpredictable shadowing of classes can arise, see Issues With Requir-
ing Bundles on page 73. However, split packages without shadowing are
explicitly permitted.
For example, take the following setup:
A: Require-Bundle: B
Export-Package: p
B: Export-Package: p;partial=true;mandatory:=partial
If bundle C imports package p, it will be wired to package A.p, however the
contents will come from B.p > A.p. The mandatory attribute on bundle B’s
export definition ensures that bundle B is not accidentally selected as
exporter for package p. Split packages have a number drawbacks that are
discussed in Issues With Requiring Bundles on page 73.
Resources and classes from a split package must be searched in the order in
which the required bundles are specified in the Require-Bundle header.

It will probably be necessary to skip using the maven-bundle-plugin and compile the bundles by hand...

[craigching]

Sorry, my posting and responses are a bit sporadic as I'm on vacation ;-)

You really don't want to use Require-Bundle except as a last resort.  Creating a super-bundle is preferable to that.  And, yes, you don't need the maven bundle plugin, you can create your own manifest if you want.