1:35 a.m.
http://pastebin.com/59X7aXaX shows the "NoSuchMethodError:
org.infinispan.AdvancedCache.keySet()Lorg/infinispan/commons/util/CloseableIteratorSet"
that we are getting when running the WildFly 10 testsuite with Hibernate
ORM 5.0.0.CR4 and Infinispan 8.0.0.Beta2.
Suggestions?
Scott
4:01 a.m.
It seems ORM was compiled with a version earlier than Beta1 but then ran
with Beta2? The keySet method was changed to return a subclass of
CloseableIteratorSet with Beta2 to support distributed streams [1].
[1]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
- Will
On Wed, Aug 5, 2015 at 7:36 PM Scott Marlow <smarlow(a)redhat.com> wrote:
http://pastebin.com/59X7aXaX shows the "NoSuchMethodError:
org.infinispan.AdvancedCache.keySet()Lorg/infinispan/commons/util/CloseableIteratorSet"
that we are getting when running the WildFly 10 testsuite with Hibernate
ORM 5.0.0.CR4 and Infinispan 8.0.0.Beta2.
Suggestions?
Scott
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:30 a.m.
On 6 August 2015 at 03:01, William Burns <mudokonman(a)gmail.com> wrote:
It seems ORM was compiled with a version earlier than Beta1 but then
ran
with Beta2? The keySet method was changed to return a subclass of
CloseableIteratorSet with Beta2 to support distributed streams [1].
Right, that's my same conclusion. Hibernate ORM is not updating to
Infinispan 8 as it needs to be released with Infinispan 7;
we previously adjusted the Hibernate code to verify that it would work
with Infinispan 8 too, but I did that by rebuilding ORM and
temporarily changing the property which defines the Infinispan
dependency version (no source code changes of course). I proposed a
Jenkins job but that didn't seem popular :-/
So it turns out it was source-code compatible but not at runtime, my
bad sorry I didn't think to verify that.
But now if we don't get it to work at runtime, that's a problem to get
Infinispan 8 in WildFly 10.
Scott, I think the most reliable way is to have you setup a WildFly
job which tests snapshots of Hibernate and Infinispan of the branches
you intend to merge next in WildFly. AFAIK it would also save you some
time, as you seem to constantly run such builds?
BTW that CacheSet API change looks like it was intended to be
backwards compatible? It's not, as we just realised. I you want it to
be backwards compatible you'll have to revert that API change.
BTW 2 .. when I verified those things it was passing the ORM
testsuite, but latest ORM with latest Infinispan now have a lot of
test failures. I had proposed to setup a Jenkins job to monitor the
combination, but need a volunteer to act on the reports. It turns out
it's not even given all the coverage we need but it would be a start.
Sanne
[1]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
- Will
On Wed, Aug 5, 2015 at 7:36 PM Scott Marlow <smarlow(a)redhat.com> wrote:
>
> http://pastebin.com/59X7aXaX shows the "NoSuchMethodError:
>
>
org.infinispan.AdvancedCache.keySet()Lorg/infinispan/commons/util/CloseableIteratorSet"
> that we are getting when running the WildFly 10 testsuite with Hibernate
> ORM 5.0.0.CR4 and Infinispan 8.0.0.Beta2.
>
> Suggestions?
>
> Scott
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:42 a.m.
On 06/08/2015 10:30, Sanne Grinovero wrote:
On 6 August 2015 at 03:01, William Burns <mudokonman(a)gmail.com>
wrote:
> It seems ORM was compiled with a version earlier than Beta1 but then ran
> with Beta2? The keySet method was changed to return a subclass of
> CloseableIteratorSet with Beta2 to support distributed streams [1].
BTW that CacheSet API change looks like it was intended to be
backwards compatible? It's not, as we just realised. I you want it to
be backwards compatible you'll have to revert that API change.
From the ORM version numbers (CR4) I guess we are near endgame and we
MUST ensure that ORM works with both Infinispan 7.x and 8.x.
Will is it possible to make the signature of the method backwards
compatible ?
If this is inconvenient, what can be done in Hibernate Infinispan to
insulate it from this change ?
Still, I'm wondering whether hibernate-infinispan shouldn't be
subclassed into multiple versions so that we can be a bit more liberal
with some changes.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
12:51 p.m.
On 6 August 2015 at 09:42, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 06/08/2015 10:30, Sanne Grinovero wrote:
> On 6 August 2015 at 03:01, William Burns <mudokonman(a)gmail.com> wrote:
>> It seems ORM was compiled with a version earlier than Beta1 but then ran
>> with Beta2? The keySet method was changed to return a subclass of
>> CloseableIteratorSet with Beta2 to support distributed streams [1].
>
> BTW that CacheSet API change looks like it was intended to be
> backwards compatible? It's not, as we just realised. I you want it to
> be backwards compatible you'll have to revert that API change.
From the ORM version numbers (CR4) I guess we are near endgame and we
MUST ensure that ORM works with both Infinispan 7.x and 8.x.
Will is it possible to make the signature of the method backwards
compatible ?
If this is inconvenient, what can be done in Hibernate Infinispan to
insulate it from this change ?
Still, I'm wondering whether hibernate-infinispan shouldn't be
subclassed into multiple versions so that we can be a bit more liberal
with some changes.
It has always been maintained by the Infinispan team. You can do that,
or you could even move the sources to the Infinispan project so you
get to pick the versions;
that would solve the current version entanglement but I wonder if we'd
end up being stuck in the opposite but similar situation.. just
something to consider.
In particular the upgrade to Hibernate ORM 5 did change the Caching
SPI, but that's not happening often at all. It looks like Infinispan
moves much quicker, so owning the module in Infinispan might make
these issues less frequent.
On a different note: it turns out it's quite easy for Gradle to
compile vs Infinispan 7 but test vs Infinispan 8,
so I've setup such a job now to trigger on each Hibernate commit, but
it will depend on a hardcoded version Infinispan 8.0.0.Beta2 because
that's all we have on Nexus.
You can checkout Hibernate ORM's master and build it with:
./gradlew clean :hibernate-infinispan:test
-PoverrideInfinispanVersionForTesting=8.0.0.Beta2
to have it run the Infinispan integration tests only. Or replace the
property value to test vs a different Infinispan version:
'8.0.0.Beta1' works fine, '8.0.0.Beta2' produces quite some failures,
we'll probably switch to use '8.0.0-SNAPSHOT' on ci.hibernate.org when
Sebastian gets Infinispan to upload nightly builds, but ideally you
should get similar jobs setup on ci.infinispan.org.
HTH
Sanne
4:17 p.m.
On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 06/08/2015 10:30, Sanne Grinovero wrote:
> On 6 August 2015 at 03:01, William Burns <mudokonman(a)gmail.com> wrote:
>> It seems ORM was compiled with a version earlier than Beta1 but then ran
>> with Beta2? The keySet method was changed to return a subclass of
>> CloseableIteratorSet with Beta2 to support distributed streams [1].
>
> BTW that CacheSet API change looks like it was intended to be
> backwards compatible? It's not, as we just realised. I you want it to
> be backwards compatible you'll have to revert that API change.
From the ORM version numbers (CR4) I guess we are near endgame and we
MUST ensure that ORM works with both Infinispan 7.x and 8.x.
Will is it possible to make the signature of the method backwards
compatible ?
The method is backwards compatible when compiling and running against ISPN
8.
I don't think there is any way here to make this backwards compatible
changing only ISPN with varying versions at runtime without adding new
methods in ISPN 8 which are identical to keySet, values and entrySet except
the return type for them are defined as returning the new
CacheSet/CacheCollection interfaces. The underlying implementation for the
duplicates would be identical however. Without those new methods we
wouldn't have access to the more advanced options when using distributed
streams unless we manually casted. This doesn't sound too appealing to me.
If this is inconvenient, what can be done in Hibernate Infinispan to
insulate it from this change ?
This code is essentially doing a clear, but can this code live with the
semantics of clear [1] that are the same between ISPN 7 & 8? I am guessing
not.
We could add a utility method in ISPN 7 & 8 that is defined as returning a
ClosebaleIteratorSet/Collection that would be identical in both versions
that we could also do [2]. Then if ORM calls the appropriate static method
instead of keySet, values, entrySet it would be backwards runtime
compatible as well.
Still, I'm wondering whether hibernate-infinispan shouldn't be
subclassed into multiple versions so that we can be a bit more liberal
with some changes.
This does hamper changes quite a bit. This change was pretty minor, I
can't imagine if they are using some class/method that we are removing in
ISPN 8.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
[1]
https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/or...
[2] https://gist.github.com/wburns/c3d3d95483d35be4b8c6
4:50 p.m.
I have already solved that using filterEntries [1], but that's not end
of the pain. Another change is ISPN removing
ExtendedModuleCommandsFactory - I could not get around that with
Infinispan snapshot. And if Infinispan does not keep fixed API even
between major versions, these attempts to sync it seem quite futile.
Radim
[1] https://github.com/hibernate/hibernate-orm/pull/1045
On 08/06/2015 04:17 PM, William Burns wrote:
On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <ttarrant(a)redhat.com
<mailto:ttarrant@redhat.com>> wrote:
On 06/08/2015 10:30, Sanne Grinovero wrote:
> On 6 August 2015 at 03:01, William Burns <mudokonman(a)gmail.com
<mailto:mudokonman@gmail.com>> wrote:
>> It seems ORM was compiled with a version earlier than Beta1 but
then ran
>> with Beta2? The keySet method was changed to return a subclass of
>> CloseableIteratorSet with Beta2 to support distributed streams [1].
>
> BTW that CacheSet API change looks like it was intended to be
> backwards compatible? It's not, as we just realised. I you want
it to
> be backwards compatible you'll have to revert that API change.
From the ORM version numbers (CR4) I guess we are near endgame and we
MUST ensure that ORM works with both Infinispan 7.x and 8.x.
Will is it possible to make the signature of the method backwards
compatible ?
The method is backwards compatible when compiling and running against
ISPN 8.
I don't think there is any way here to make this backwards compatible
changing only ISPN with varying versions at runtime without adding new
methods in ISPN 8 which are identical to keySet, values and entrySet
except the return type for them are defined as returning the new
CacheSet/CacheCollection interfaces. The underlying implementation
for the duplicates would be identical however. Without those new
methods we wouldn't have access to the more advanced options when
using distributed streams unless we manually casted. This doesn't
sound too appealing to me.
If this is inconvenient, what can be done in Hibernate Infinispan to
insulate it from this change ?
This code is essentially doing a clear, but can this code live with
the semantics of clear [1] that are the same between ISPN 7 & 8? I am
guessing not.
We could add a utility method in ISPN 7 & 8 that is defined as
returning a ClosebaleIteratorSet/Collection that would be identical in
both versions that we could also do [2]. Then if ORM calls the
appropriate static method instead of keySet, values, entrySet it would
be backwards runtime compatible as well.
Still, I'm wondering whether hibernate-infinispan shouldn't be
subclassed into multiple versions so that we can be a bit more liberal
with some changes.
This does hamper changes quite a bit. This change was pretty minor, I
can't imagine if they are using some class/method that we are removing
in ISPN 8.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
[1]
https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/or...
[2] https://gist.github.com/wburns/c3d3d95483d35be4b8c6
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
6:04 a.m.
On Thu, Aug 6, 2015 at 10:39 PM Radim Vansa <rvansa(a)redhat.com> wrote:
I have already solved that using filterEntries [1], but that's
not end
of the pain. Another change is ISPN removing
ExtendedModuleCommandsFactory - I could not get around that with
Infinispan snapshot. And if Infinispan does not keep fixed API even
between major versions, these attempts to sync it seem quite futile.
I integrated the module command factory change in ISPN master earlier
today. I was able to run the infinispan hibernate tests and they worked
for me with your PR applied. Is there some other thing I needed to run?
And since we know to watch out for the binary compatibility we can make
sure it stays that way for the 8.0 Final release.
Radim
[1] https://github.com/hibernate/hibernate-orm/pull/1045
On 08/06/2015 04:17 PM, William Burns wrote:
>
>
> On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <ttarrant(a)redhat.com
> <mailto:ttarrant@redhat.com>> wrote:
>
>
>
> On 06/08/2015 10:30, Sanne Grinovero wrote:
> > On 6 August 2015 at 03:01, William Burns <mudokonman(a)gmail.com
> <mailto:mudokonman@gmail.com>> wrote:
> >> It seems ORM was compiled with a version earlier than Beta1 but
> then ran
> >> with Beta2? The keySet method was changed to return a subclass of
> >> CloseableIteratorSet with Beta2 to support distributed streams
[1].
> >
> > BTW that CacheSet API change looks like it was intended to be
> > backwards compatible? It's not, as we just realised. I you want
> it to
> > be backwards compatible you'll have to revert that API change.
>
> From the ORM version numbers (CR4) I guess we are near endgame and
we
> MUST ensure that ORM works with both Infinispan 7.x and 8.x.
> Will is it possible to make the signature of the method backwards
> compatible ?
>
>
> The method is backwards compatible when compiling and running against
> ISPN 8.
>
> I don't think there is any way here to make this backwards compatible
> changing only ISPN with varying versions at runtime without adding new
> methods in ISPN 8 which are identical to keySet, values and entrySet
> except the return type for them are defined as returning the new
> CacheSet/CacheCollection interfaces. The underlying implementation
> for the duplicates would be identical however. Without those new
> methods we wouldn't have access to the more advanced options when
> using distributed streams unless we manually casted. This doesn't
> sound too appealing to me.
>
> If this is inconvenient, what can be done in Hibernate Infinispan to
> insulate it from this change ?
>
>
> This code is essentially doing a clear, but can this code live with
> the semantics of clear [1] that are the same between ISPN 7 & 8? I am
> guessing not.
>
> We could add a utility method in ISPN 7 & 8 that is defined as
> returning a ClosebaleIteratorSet/Collection that would be identical in
> both versions that we could also do [2]. Then if ORM calls the
> appropriate static method instead of keySet, values, entrySet it would
> be backwards runtime compatible as well.
>
>
> Still, I'm wondering whether hibernate-infinispan shouldn't be
> subclassed into multiple versions so that we can be a bit more
liberal
> with some changes.
>
>
> This does hamper changes quite a bit. This change was pretty minor, I
> can't imagine if they are using some class/method that we are removing
> in ISPN 8.
>
>
> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:
infinispan-dev(a)lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> [1]
>
https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/or...
>
> [2] https://gist.github.com/wburns/c3d3d95483d35be4b8c6
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:33 p.m.
Scott, I think the most reliable way is to have you setup a WildFly
job which tests snapshots of Hibernate and Infinispan of the branches
you intend to merge next in WildFly. AFAIK it would also save you some
time, as you seem to constantly run such builds?
I think that we talked about doing that a few years ago. I setup a CI
job that built Hibernate master, Infinispan master and tried to build
WildFly with the two but it didn't work. One of the problems was that
WildFly wouldn't build without code/configuration changes to adjust for
the Infinispan (master) changes that had been made since the version of
Infinispan that was integrated.
https://github.com/wildfly/wildfly/pull/7896 is the pull request for
upgrading WildFly 10 to use Infinispan 8. I'm not sure how much of it
is optional but I'm guessing a lot of the changes are needed for WildFly
to work at all with Infinispan 8.
In order for this testing to work, Infinispan would need to maintain
compatibility (e.g. configuration/api/spi) for at least one major
version back. I'm not sure if there are any other problems to overcome
before doing WildFly/Hibernate/Infinispan testing.
I suppose that another problem, when we integrate the latest WildFly
master the latest master branches for Infinispan/Hibernate, we will
likely see failures as new features are being developed (not everything
works on day one of a new major release cycle). Its probably closer to
the end of a development cycle (when all three development teams are
ready to be spammed that they have integration bugs that need to be
fixed). But, if we all agree that we need to keep integration working
from the start of a new major release cycle, this could work. We also
need to sign off on keeping compatibility as mentioned above.
Does Infinispan want 8.0 to be fully (configuration/API/SPI) compatible
with 7.x? How about 9.0 with 8.0?
Scott
8:49 p.m.
Hi Scott,
On 6 August 2015 at 13:33, Scott Marlow <smarlow(a)redhat.com> wrote:
>
> Scott, I think the most reliable way is to have you setup a WildFly
> job which tests snapshots of Hibernate and Infinispan of the branches
> you intend to merge next in WildFly. AFAIK it would also save you some
> time, as you seem to constantly run such builds?
I think that we talked about doing that a few years ago. I setup a CI
job that built Hibernate master, Infinispan master and tried to build
WildFly with the two but it didn't work. One of the problems was that
WildFly wouldn't build without code/configuration changes to adjust for
the Infinispan (master) changes that had been made since the version of
Infinispan that was integrated.
https://github.com/wildfly/wildfly/pull/7896 is the pull request for
upgrading WildFly 10 to use Infinispan 8. I'm not sure how much of it
is optional but I'm guessing a lot of the changes are needed for WildFly
to work at all with Infinispan 8.
I agree, that would be horrible. The two are different independent
projects, and hoping that the two masters work flawlessly with each
other every day would be a foolish assumption: that's *not* what I
suggested.
What I suggested is that you have a job running which monitors the two
branches which you're planning to get working together, and ideally
within WildFly too. In this specific case, they happen to be {master}
and {master} of each project, but that's a coincidence as that's the
current aim: we intentionally want these two versions to work together
in the same platform.
And things seemed to work a week ago... what was really disappointing
today, was to figure out that there was a regression *after* we tagged
the ORM release.
When we reach such a point in which it looks like they are converging
fine, that's when we need to setup such a WildFly CI job: if only we
had known yesterday before the release, you'd be merging them both in
WildFly today. Or someone could have run a manual test, but this could
be done by a bot.
In order for this testing to work, Infinispan would need to maintain
compatibility (e.g. configuration/api/spi) for at least one major
version back. I'm not sure if there are any other problems to overcome
before doing WildFly/Hibernate/Infinispan testing.
Both projects need to be able to freely evolve between major versions.
But occasionally, someone from the WildFly team is going to start
planning and pick versions from these projects - not necessarily the
latest - at that point you start testing and see if the choice is
valid, request integration fixes, and should also reconfigure the
"convergence jobs".
It sounds like you spend a lot of time testing such integrations, so
we should automate those builds and make sure we get preventive
reports: saves a lot of critical time.
I suppose that another problem, when we integrate the latest WildFly
master the latest master branches for Infinispan/Hibernate, we will
likely see failures as new features are being developed (not everything
works on day one of a new major release cycle). Its probably closer to
the end of a development cycle (when all three development teams are
ready to be spammed that they have integration bugs that need to be
fixed). But, if we all agree that we need to keep integration working
from the start of a new major release cycle, this could work. We also
need to sign off on keeping compatibility as mentioned above.
Does Infinispan want 8.0 to be fully (configuration/API/SPI) compatible
with 7.x? How about 9.0 with 8.0?
No those are obviously non viable options; for example I think the
specific change in Infinispan which caused all this trouble is
perfectly fine: there are lots of things which can be done, the
problem is just that we're notified of these problems very late in the
game.
Both projects need to experiment and evolve without expensive
constraints, we only need specifically selected branches to work
together.
Thanks,
Sanne
Scott
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3241
days inactive
3243
days old
infinispan-dev@lists.jboss.org
9 comments
5 participants
participants (5)
-
Radim Vansa -
Sanne Grinovero -
Scott Marlow -
Tristan Tarrant -
William Burns