I repeatedly get this error below from the webserver sending indexing JMS messages. This is new, at least I haven't seen these errors prior to today (yesterday we did a big update to our codebase and libraries), but the ethernet connection between the webserver and JMS server seems perfect, so I'm not sure what this error means exactly. It happens very roughly once every several hundred messages? I guess my big question is what the effects of this are? Does the data in the message causing the exception not get indexed? Does it get retried?


Exception in thread "Hibernate Search: backend queueing processor-2" org.hibernate.HibernateException: Unable to send Search work to JMS queue: java:comp/env/queue/hibernatesearch
at org.hibernate.search.backend.impl.jms.JMSBackendQueueProcessor.run(JMSBackendQueueProcessor.java:85)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.jms.JMSException: Wire format negotiation timeout: peer did not send his wire format.
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1266)
at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1350)
at org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:300)
at org.apache.activemq.ActiveMQConnection.createQueueSession(ActiveMQConnection.java:1192)
at org.hibernate.search.backend.impl.jms.JMSBackendQueueProcessor.run(JMSBackendQueueProcessor.java:74)
... 3 more
Caused by: java.io.IOException: Wire format negotiation timeout: peer did not send his wire format.
at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:98)
at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:74)
at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:79)
at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1244)
... 7 more

Seems to be more of a activemq problem. Have a look at this for example - http://activemq.apache.org/javaxjmsjmse ... ormat.html

@Hardy, what does it mean for hibernate search? Did I lose these index requests? Does hibernate search retry a jms message upon these kinds of errors?

Yes, you probably lost some indexing requests. Search does not have any retry functionality in the JMS part. It is basically the responsibility of the JMS provider/configuration to ensure that the messages get delivered properly. As you can see in the ActiveMQ documentation there are several ways to configure failover and reconnection attempts.

--Hardy

@Hardy, it sure would be nice for hibernate search to include some kind of retry or safety feature.. If the JMS server is down, I hate to lose so much in our index during that time... I'm entirely dependent on the JMS server or cluster never being unavailable.

hi mueller,
JMS does include all safety features you might need, if setup properly it will guarantee the message is delivered; if the server is down, it will be transmitted when it goes up again.
That's the cool thing of using JMS: we don't have to reinvent the wheel.

umm.. didn't Hardy just say, "you probably lost some indexing requests?" You're saying if the JMS server is down, Hibernate Search will ensure the indexing request "will be transmitted when it goes up again?" Is that because java/spring's JMS client will store that message temporarily somewhere and poll the JMS server? Or Hibernate Search does this?

Hibernate Search doesn't have to try again as JMS should care about it storing the message somewhere - it's a configuration detail of all JMS implementations (it must be supported as the JMS spec mandates it, that's the main reason IMHO to use JMS).