Troubleshoot Your JavaScript JMS Client

This topic contains descriptions of common errors that can occur when using the JavaScript client and provides steps on how to prevent these errors.

Before You Begin

This procedure is part of Checklist: Build JavaScript JMS Clients.

Note: Learn about supported browsers, operating systems, and platform versions in the Release Notes.

What Problem Are You Having?

Illegal State Exception

Cause: This message usually means that you are using Connection.start(), Connection.close(), Connection.create(), Transaction.commit(), Transaction.rollback(), or Producer.send() and the interface is not fully completing its function before initializing the "future" handler. For example, when using Connection.start(), all message processing must start properly before calling connectionFuture.

Solution: To prevent this error, when creating a JavaScript JMS client, you must allow each of the listed interfaces to complete its function. A callback passed as an argument to these functions will be called when the operation is completed. See the JavaScript JMS Client API documentation for more information.

Error When Using new TextMessage()

Cause: When running a JavaScript JMS client that uses new TextMessage() in your JavaScript JMS client, you get an error.

Solution: To prevent this error, use session.createTextMessage instead. See the JavaScript JMS Client API documentation for more information.

Expected Messages Are Not Being Received for a Queue or Durable Subscriber

Cause: If expected messages are not being received for a queue or durable subscriber, then it could be because the application has received messages without acknowledging them. The Gateway will send a maximum of maximum.pending.acknowledgments messages until the client acknowledges. The maximum.pending.acknowledgments property is set to 1 for JMS providers that do not support individual message acknowledgement.

Solution: If you are using a JMS provider other than Apache ActiveMQ or TIBCO Enterprise Message Service (TIBCO EMS), you must ensure your client applications acknowledge each message received from a queue or durable subscriber.

400 Bad Request Error During Authentication Using Internet Explorer

Cause: Internet Explorer caches credentials by default. For example, if a client in Internet Explorer performs Negotiate authentication to obtain a token and then attempts to use Basic Authentication for a username and password, the client in Internet Explorer responds by sending a Negotiate scheme instead of the Basic scheme, resulting in a 400 Bad Request.

Solution: Clear the Internet Explorer credential cache in your client after the first HTTP request using the following JavaScript code:

document.execCommand('ClearAuthenticationCache', 'false');

Next Step

Display Logs for the JavaScript JMS Client