Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes in JBoss AS 7 shutdown process causing problems during Spring's application context destruction [SPR-11003] #15631

Closed
spring-projects-issues opened this issue Oct 18, 2013 · 6 comments
Assignees
Labels
in: core status: invalid

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 18, 2013

Michal Jemala opened SPR-11003 and commented

The problematic situation occurs when a Spring-based application is running within JBoss AS v7, where JBoss has changed the shutdown sequence which renders certain cleanup procedures (bound to the destruction phase of Spring's application context) invalid.

More specifically, the ability to access JMS resources after shutdown has been initiated (same applies to the JDBC resources) has been compromised. By checking the logs you can spot that both JDBC datasources as well as JMS destinations, are both being unbound from JNDI before the web application context destruction is initiated.

A simple way to replicate this issue is to deploy an application with DataSourceInitializer and its databaseCleaner property configured. Then, when the AS is being shutdown the "ResourceException: IJ000451: The connection manager is shutdown" is raised and DB cleanup will not be executed.

Obviously this is not a Spring Framework issue and all the blame goes to the JBoss AS. However, I would like to verify this and check there is no known workaround on Spring side, which can be deployed to avoid this?


Reference URL: https://issues.jboss.org/browse/WFLY-944

Attachments:

1 votes, 6 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 18, 2013

Michal Jemala commented

Testing the same demo app on JBoss AS 8 (a.k.a WildFly) showed the issue has been addressed although the WFLY-944 is still unresolved.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 22, 2013

Stéphane Nicoll commented

Following what the RedHat support told us we have forced the binding of such resources to our web-app. This is what we added to web.xml

    <resource-ref id="hornetq-ra">
        <res-ref-name>hornetq-ra</res-ref-name>
        <res-type>javax.jms.QueueConnectionFactory</res-type>
        <res-auth>Container</res-auth>
        <lookup-name>java:/JmsXA</lookup-name>
    </resource-ref>

    <resource-ref id="NettyConnectionFactory-ra">
        <res-ref-name>NettyConnectionFactory</res-ref-name>
        <res-type>javax.jms.QueueConnectionFactory</res-type>
        <res-auth>Container</res-auth>
        <lookup-name>java:/XAConnectionFactory</lookup-name>
    </resource-ref>

    <resource-ref id="NettyThroughputConnectionFactory-ra">
        <res-ref-name>NettyThroughputConnectionFactory</res-ref-name>
        <res-type>javax.jms.QueueConnectionFactory</res-type>
        <res-auth>Container</res-auth>
        <lookup-name>java:/XAThroughputConnectionFactory</lookup-name>
    </resource-ref>

That did the trick for us and probably an extra resource binding for the connection factory would fix any issue with JDBC resources access on shutdown.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 31, 2014

James Livingston commented

[disclaimer: I work for Red Hat on JBoss things]

I agree that this isn't a Spring issue, but it's also not a JBoss issue - it's an application one. Using <resource-ref> isn't a workaround or a trick, it's simply the way you are supposed to do it (ideally using java:comp/env/... to look them up too).

Declaring resources in your web.xml tells the container you need them, so it makes them available and ensure they work for the duration of your application's lifecycle. If you do not declare them, then they may also not be available during initialisation (as well as destroyed before shutdown). JBoss certainly isn't the only EE container where this can happen, it just may occur more often on JBoss because it aggressively does work in parallel.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2014

Stéphane Nicoll commented

[disclaimer: since I wrote that comment I actually joined Pivotal and the Spring framework team]

Thanks for the reply James. I would tend to agree if the services we are talking about weren't core services provided by the container (and the spec). Why would you want to stop something like the JMS broker while the deployed (external) applications have not been shutdown yet? As you said, for optimizations. But can't you guys look at the current usage of the broker and postpone shutdown when you still have registered sessions? Just a thought. Thanks.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2014

Juergen Hoeller commented

Alright, I'll mark this issue as 'invalid' then. Please do use the suggested resource-ref declarations, or lobby towards JBoss to be smarter in auto-detecting resource use...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 1, 2014

James Livingston commented

JBoss does ensure it stays alive if it knows of any references in the application, such as <resource-ref> entries, @Resource/@EJB/@Inject annotations and so on. The problem only really occurs for things where an application (or library like Spring) code does a programmatic JNDI lookup, since the container can't know for sure when it is not longer needed.

Trying to guess tends to end badly, and doesn't entirely solve the problem. For example if an app is otherwise idle but needs a new JDBC connection during shutdown, then it would still fail. Real applications tend to do things like store references to services in static variables, and we don't want to break them or hang during shutdown either.

If there is a clear split between "container services" which provide things and application which consume them, then a two-phase shutdown can work well - shut down the apps, then shut down the services. It doesn't work for more complex situations when applications provide services as well (EJBs, declarations of queues/topics/datasources), and container services can require other components before they are available.

@spring-projects-issues spring-projects-issues added status: invalid in: core type: task labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: task label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: invalid
Projects
None yet
Development

No branches or pull requests

2 participants