JMS queue initialized too early w/o re-try on failure

Description

Using the JMS backend, if your app is deployed during server start / restart, it fails to start as it can not look up the JMS queue yet. Once it fails, there is no retry and the app must be re-deployed. The queue is not fully deployed until after the hornetq server is started.

Environment

None

Activity

Show:
Emmanuel Bernard
July 4, 2015, 1:41 PM

I happen to touch that area for HSEARCH-668.
Matt, so the initializeJMSQueueConnectionFactory passes but the initializeJMSQueue fails?
It's interesting as both do a JNDI lookup on JMS-ish things.

In the TX code for HSEARCH-668, we do delay the queue and connection lookup to just in time and we do them each time. I was wondering about the perf cost but that might solve your problem.

Matt Robson
July 5, 2015, 12:05 AM

The connection factory is created and bound very early on, even before the deployment of the users archive.

Based on what I see here, the connection is not created for every request, simply retrieved, only the session is. Looking at the code for HSEARCH-668, the TX use case does seem to call createQueueConnection for every request and also seems like it would a JNDI lookup of the queue for every request. I think no longer eagerly initializing the CF and Queue object during initialize() is a good way to solve this, it just needs a little tweak so it doesn't create a connection or lookup the queue every time.

Something like, because in the case of the queue, being transnational is not relevant.

Emmanuel Bernard
July 6, 2015, 8:31 AM

FTR, we would need some volatile pixie dust. And we would lose the ability to detect incorrect configuration at startup time. It would only happen the first time an index change is requested.

Hardy Ferentschik
July 6, 2015, 11:19 AM

FTR, we would need some volatile pixie dust. And we would lose the ability to detect incorrect configuration at startup time. It would only happen the first time an index change is requested.

That is also my concern. Actually it would help to have a sample application showcasing this problem. could you attach one?

Matt Robson
July 6, 2015, 4:37 PM

Ya, I agree, but it seemed like it was moving in the direction as per HSEARCH-668.

I attached my slave WAR, source code is here: search-slave.

Full project and setup is here: hibernate-search-infinispan-jms.

Might be easier to just provide the full lab to you offline as it takes a little to set it all up.

Assignee

Unassigned

Reporter

Matt Robson

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Fix versions

Priority

Critical
Configure