nadirx I doubt so; since wiebe replaced the cache name with X I suppose this was an entity (or collection...) cache, not a pending puts cache. Also the cache is undefined from elsewhere IIRC (as the Hibernate's SessionFactory.close() is called), but not in the stop() which is a bit weird.
I've recently debugged into similar issue where a silently swallowed exception from WF's interceptor stack caused the session factory to not be closed, though it was more of a test problem. So this might be similar, but without a reproducer we can't tell.
smarlow Does this ring any bells?
I will not be able yet to verify if an upgrade to 9.2.3 fixes the issue (we do not own that top-level dependency management in my project). But I have found a fix for my issue for now.
When adding artifacts to my deployment for Wildfly 12 Intellij automatically adds a build step for building the artifacts. However, in a maven multi-module project this did not work correctly. The target/ folders delivered for doing a full project build vs. individual modules has differences, causing my issues. Beginner's mistake it seems. I have to find time to analyse these exact differences, but for now I simply do not build single artifacts anymore. What I do now already know is that I probably ended up with a jar being included that was not included with a full project build.
Thanks for the help!
@rvansa: I did not actually replace a cache with name 'X', that was a placefolder as to not disclose sensitive information. The issue did only occur with different pending-puts caches. I'll have to see in a later upgrade for Infinispan whether that has any impact.
One related issue that we are seeing is with deployments that have multiple persistence units with the  WildFly branch, when using Hibernate ORM 5.3.0.Final. Gail thinks that there may be a collision between the two persistence units, on timestamps cache, because it seemed like the entity region prefix was not being used and both persistence units had the same entity class in it.
Of course, we shouldn't ever have the same entity class mapped to more than one persistence unit, because that could lead to unexpected behaviour. Also, we think the timestamp issue could be a Hibernate ORM 5.3.0.Final bug that Gail is looking into.
My question is whether this application deployment getting the "Attempt to define configuration for cache X which already exists", has more than one persistence unit defined?
We do not share entities between persistence units; we only have a single one defined in the entire project.