Troubleshoot Your Microsoft .NET JMS Clients

This procedure provides troubleshooting information for the most common issues that occur when using Kaazing Gateway Microsoft .NET clients.

Before You Begin

This procedure is part of Checklist: How to Build Microsoft .NET JMS Clients.

To Troubleshoot Your Microsoft .NET JMS Clients

The following are some things that can go wrong when using the .NET clients:

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

Debug Log Produces an Error

When debugging an application from Visual Studio, the debug log gives you a disconnecting message or an error.

Cause

This message usually means that you are trying to debug an application from Visual Studio and using the incorrect cross-site-constraint to connect to Kaazing Gateway services.

Action

A cross-site-constraint of * is required to connect to Kaazing Gateway services when debugging applications from Visual Studio using a file:// based URL.

Delay to Initial Connection Request from the .NET Client

The initial WebSocket connection from the .NET client built using Kaazing Gateway client library for .NET delayed by several seconds.

Cause

The delay may be caused by automatic proxy detection in Windows.

Action

To address this, if using Internet Explorer, choose Options > Connections tab > LAN Settings. Clear the Automatically Detect Settings checkbox and, if necessary, specify the proxy settings. In .NET applications, you can bypass the proxy settings by including the line System.Net.WebRequest.DefaultWebProxy = null; before the client initiates the WebSocket connection. If your application requires a proxy, change the null value in this line to the default proxy or follow these instructions.

To get more troubleshooting information for your .NET clients, see Display Logs for .NET Clients.

.NET client has reached connection limit

The .NET client has reached a maximum connection limit per domain of two connections.

Cause

The Microsoft .NET 4.0 Framework has a maximum connection limit of two per domain, similar to the browser limitation.

Action

For any Microsoft .NET application that uses more than one WebSocket connection at a time, you must either ensure that any WebSocket connection is closed by using WebSocket.Close() before opening another WebSocket connection, or increase the connection limit on the application by updating the maxconnection attribute in the app.config file. For more information about the error and tuning .NET client connections, see (KG-1851) Two Connection Limit in Kaazing JMS Clients for Microsoft .NET in the Release Notes.

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.

Action: 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.

Error when deploying a .NET Android client from Xamarin on a virtual device running Intel Atom CPU/ABI and Android API Level 19

Cause: Deploying a .NET JMS client to Android from Xamarin on a virtual device created with Intel Atom CPU/ABI and Android API Level 19 may cause connection errors. See a similar issue Application fails to deploy to Android Intel emulator on API 19 (Platform 4.4.2) on Stack Overflow.

Solution: For more stable performance, use a virtual device created with the ARM CPU/ABI instead of the Intel Atom CPU/ABI.

Next Step

You have completed the Microsoft .NET client procedures. For more information on client API development, see the .NET Client API.