I've also observed this behavior. By not calling close on the pool it leaves at least one background timer thread running holding a reference to the pool itself.

IIRC, I had tracked it down to the root cause of when the service registry is destroyed in the SessionFactory close it doesn't walk up the chain destroying the parents.

From AbstractServiceRegistryImpl

@Override
    @SuppressWarnings( {"unchecked"})
	public void destroy() {
		synchronized ( serviceBindingList ) {
			ListIterator<ServiceBinding> serviceBindingsIterator = serviceBindingList.listIterator( serviceBindingList.size() );
			while ( serviceBindingsIterator.hasPrevious() ) {
				final ServiceBinding serviceBinding = serviceBindingsIterator.previous();
				serviceBinding.getLifecycleOwner().stopService( serviceBinding );
			}
			serviceBindingList.clear();
		}
		serviceBindingMap.clear();
	}

This only works on the direct serviceBindingList and doesn't destroy any of the parent services.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira