Excellent.
I think this will do in the short term, but in the long term, I think we
need to revisit some of the finer points of the cache manager lifecycle,
especially within the context of Wildfly/EAP.
In Wildfly/EAP, 2 deployment thread can easily trigger a case where a
cache manager is restarted using the same GlobalConfiguration instance.
The root of the problem, I think, is that the GlobalConfiguration and
cache Configuration objects currently have references to
stateful/runtime objects like VersionAwareMarshaller. I think this is a
bad idea. Ideally, the GlobalConfiguration object would simply contain
a factory for creating instances of the marshaller. The marshaller
instance would only be instantiated as part of the cache/cache manager
startup process. This way, the same GlobalConfiguration object can be
use to create any number of cache managers. That would make Wildfly/EAP
very happy.
Paul
On Wed, 2013-11-13 at 10:49 +0100, Galder Zamarreño wrote:
On Nov 13, 2013, at 10:09 AM, Galder Zamarreño
<galder(a)redhat.com> wrote:
> Hey Paul,
>
> I've got a unit test for ISPN-3698 [1] [2].
>
> The test hangs when in cm1.getCache() at the end of the test. If you look at the
logs you'll find a load of NPEs like the one in the JIRA.
>
> If this is what you are doing, another thing that should work fine is essentially
rebuild the configurations when you start a new cache manager and avoid using the
configuration objects of a stopped cache manager.
>
> The key thing here is that if you create a new instance of
GlobalConfigurationBuilder when you redeploy, it'll automatically create a brand new
instance of VersionAwareMarshaller, and that would get around the issue.
>
> As long as the new global configuration has a reference to the old
VersionAwareMarshaller, you have the potential for the NPE (unless you do some trick to
reset VersionAwareMarshaller's defaultMarshaller instance).
>
> WRT the fix I proposed it yesterday, I've run it through our testsuite and a
fair few failures appear (~60), so think whether you can get around it with a workaround
like the one explained in this email. In the mean time I'm trying to find a better fix
within Infinispan itself.
^ The fix had some issues with those tests that rewire components, but I've fixed
that now and I'll send a PR right away.
Cheers,
>
> Cheers,
>
> [1]
https://issues.jboss.org/browse/ISPN-3698
> [2]
https://gist.github.com/9d5ab3623f57ec8b23ee
> --
> Galder Zamarreño
> galder(a)redhat.com
>
twitter.com/galderz
>
> Project Lead, Escalante
>
http://escalante.io
>
> Engineer, Infinispan
>
http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org