Slow CI slaves?
by Sanne Grinovero
Hi all,
are the CI slaves in good condition?
I've sent a PR 17 hours ago and it has still not produced a report.
Since I'm having a puzzling failure locally, it would be useful to
compare with the CI results and its failure history.
Should we add some more slaves? There are free servers available in OS1.
Sanne
10 years, 9 months
Merging of integration testing modules
by Sanne Grinovero
Hi all,
as I was exploring the source tree for potentially interesting tests
to run on WildFly 9, I'm getting a bit confused by the amount of
testing modules.
For example, I have no idea why there is a module
"infinispan-embedded-query-it" which apparently contains some more
tests for "infinispan-query" - but above all I'm not seeing why such
tests should be living in a separate module.
Also, it looks like there might possibly be quite some redundancy on
top of existing tests.
In a similar way, I'm aware "infinispan-as-lucene-integration" was
just created as we migrated those from Hibernate Search. But we could
merge that in our existing integration tests right?
Ideally I was hoping that an activity like a WildFly upgrade would
touch just a couple of modules; I think the only reason we should have
to separate these in different modules is if it's really important to
not have some module installed.
If we could achieve that, it should be easier to then start the
container only once (twice) to run all tests quicker?
Thanks,
Sanne
10 years, 9 months
Hanging state transfer
by Sanne Grinovero
Hi all,
any idea or suggestion please? Thread dumps are attached.
It's running two WildFly 9 instances, in "standalone" mode so I don't
expect other JGroups channels to be open.
I deploy an Hibernate Search application in them, and this simply
starts a CacheManager. That hangs on start().
If I run the exact same test, with exact same Infinispan version
(7.1.1.Final) on WildFly 8.2 + the as modules (embedded) distributed
by the Infinispan release it works just fine.
Wildfly 9 includes this Infinispan version, so the difference is that
now I'm running the modules which are shipped with WildFly 9 directly:
this should work for end users w/o additional downloads.
Don't take the current master of WF9 as reference: there are some
(other) problems with these modules, so I'm fixing them.. the other
problems were classloader / Search / Hibernate related and I have
patches for those, this run is using them.
But this one I don't understand? Any idea of what to look for? It's
probably caused by some extension point too much, or too few, but it's
not giving a hint.
Another notable difference, is that Infinispan 7.1.1.Final shipped
with JGroups 3.6.1.Final - so that's what I'm using in the version
which works - while WildFly 9 is using JGroups 3.6.2.Final.
I've tried to patch WildFly9 to use the older JGroups but it didn't
change the result.
Thanks,
Sanne
10 years, 9 months
Preparing for 7.2.0.CR1 for Friday
by Tristan Tarrant
Hi all,
we should be releasing 7.2.0.CR1 on Friday and we have several pending
PRs that need to be reviewed and pushed by then. Can I please ask
everybody to spend some extra time reviewing and pushing these ?
Thanks
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years, 10 months
My weekly update
by Tristan Tarrant
Hi all,
unfortunately I cannot attend today's weekly update. So here it is
(together with the previous week, because we skipped last week's):
Galder and I had a very productive 4 day face-to-face at my place
talking about the Infinispan 8 API changes. We also met with Mario Fusco
of Drools and "Java 8 in Action" fame who gave us some really precious
suggestions. Galder has collected most of the ideas on the "cache" side
whereas I will soon write-up the plans for the "container".
As for coding, here's a breakdown by Jira:
ISPN-5355 - fixed: it was a bug lurking under some wrong assumptions in
the configuration inheritance code.
ISPN-5359 - removed some really old server parsers. We should actually
remove some more during the 8.x cycle.
ISPN-5147 - replaced all of the server attribute/add/remove handlers so
that we don't trigger a global "require-reload" from the server, but
just restarting the affected cache. I want to extend this so that server
attributes actually "know" whether a configuration attribute is runtime
modifiable so that we can apply it immediately.
ISPN-5351 - make sure that certain attributes get copied correctly
between configurations (especially TypedProperties)
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years, 10 months
