We Keep Coding

Getting an error “Response code: Non HTTP response code: org.apache.http.conn.HttpHostConnectException” in jmeter

I am running a Load Test on my .Net web application using Jmeter.
Application Process: Launch - Login - Start Test - Answer Q&A - Home Page - Logout
Till 500 users or sometimes 750, the test is running successfully. But when I increase the load I get an Error:
Non HTTP response code: org.apache.http.conn.HttpHostConnectException/Non HTTP response message:
Connect to www.demoname.com:80 [www.demoname.com\/11.111.111.111] failed: Connection timed out: connect
'11.111.111.111' - is my Server IP address
I have increased the jmeter.batch file Heap memory to HEAP=-Xms1g -Xmx4g -XX:MaxMetaspaceSize=256m
Apache Jmeter version - 5.1.1r1855137
Java Version - 1.8.0_221
Server Configuration: Standard D4 v2 (8 vcpus, 28 GiB memory)
How can I get rid of this error?

HttpHostConnectException is basically an instance of a ConnectException which:
Signals that an error occurred while attempting to connect a socket to a remote address and port. Typically, the connection was refused remotely (e.g., no process is listening on the remote address/port).
So most probably the error is on your server side because JMeter attempts to establish the connection and fails to do this within the bounds of the defined timeout
If you're absolutely sure that your application works normally you can increase connect timeout in HTTP Request Defaults
However a better idea would be getting to the bottom of the error and fixing it on server side, the most possible reasons are in:
your application is overloaded, i.e. lacks essential resources like CPU, RAM, Network, etc. Make sure to set up monitoring of these metrics using i.e. Azure Monitor or JMeter PerfMon Plugin
your application infrastructure is not properly configured, make sure to double check if your backend is properly tuned for high loads including IIS and MSSQL
it might be the case your application code is problematic, i.e. it cannot handle more than X users due to poorly implemented algorithms. Consider using a profiler tool like NProfiler or dotTrace to detect the most expensive functions, largest objects, etc.

Azure MobileApp Client SDK crashes on Xamarin.Forms (Android)

The reproduce the error, I've created a blank mobile app and a new sql database.
Afterwards I've followed the quickstart guide and downloaded the backend and the Xamarin.Forms project.
I've deployed the Web-App to azure and started the Android app using the 5'' KitKat (4.4) XXHDPI Phone (Android 4.4 - API 19) emulator.
As soon as I add an item to the TodoItem - List (you see, it's the default sample app of xamarin mobile apps), the todoTable.InsertAsync call fails.
Unfortunately, there is no detailed error.
It's just a error message telling "An unhandled exception occured".
In the output window, I can see the following error:
03-01 19:48:33.781 I/MonoDroid( 1512): UNHANDLED EXCEPTION:
03-01 19:48:33.793 I/MonoDroid( 1512): Microsoft.WindowsAzure.MobileServices.MobileServiceInvalidOperationException: The request could not be completed. (Internal Server Error)
03-01 19:48:33.793 I/MonoDroid( 1512): at Microsoft.WindowsAzure.MobileServices.MobileServiceHttpClient+<ThrowInvalidResponse>d__24.MoveNext () [0x001ec] in <42e24ce875d34485ad11c4f8aebb904a>:0
So I've had a look at the azure mobile app in the azure portal.
Before I've ran the tests, I've enabled almost all the logs.
I can see FREB-Protocols I can see a post request to /tables/TodoItem which failed with http 500. Unfortunately it does not tell my anything about the error itself. Authentification is disabled, so the authentification should not cause any problems.
I've included the whole log here:
https://1drv.ms/b/s!AqCo2Ottp6L6wC7-nOFkDN7cERE6
Does anyone got any idea what could be wrong? Sitting here since far to many hours, guessing what could be wrong.

The Internal Server Error means your service is crashing - that's why it is not producing any logs. You've not shared anything about your backend, but that is where your problem is.
Run the service locally and attach a debugger and step through the backend code. You can find details of running the service locally (attached to a local SQL instance) in the HOWTO documents on learn.microsoft.com.

Error consuming web service: An existing connection was forcibly closed

I have a Winforms appplication written in C# that consumes web services from a Windows 2008 IIS Coldfusion server. All the web service calls succeed but one, which fails about 50% of the time with the following error:
System.InvalidOperationException was unhandled by user code
Message=There is an error in XML document (1254, 7).
with an inner exception of:
InnerException: System.IO.IOException
Message=Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
I checked my IIS logs and I get a 503 error (Service Unavailable) and an IIS code of 64 (The specified network is no longer available). Any suggestions would be great.
I run my web service in SOAP UI and I get the following error:
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
This code works fine at one company but this error pops up almost every time for this company I'm currently working with.

I'm not sure this is applicable to the OP's specific situation, but this may help others who arrive here nowadays. One potential cause for this exception involves mismatched security protocols. If the server you're calling requires TLS 1.2 and you're using an older version of ASP.net (<= Version 4.0) you will be using an older security protocol to make your calls unless you change it. You can force ASP.net to use TLS 1.2 (shown below). This can be done anywhere in the application, but I put it just before the line that calls the web service requiring TLS 1.2:
using System.Net;
...
//Enable TLS 1.2
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
// Call the Web Service that requires TLS 1.2

I recently got a similar message when consuming a WCF-Webservice. In my case it turned
out to be a configuration error on the server side. Maybe something is configured differently
on the one server where this happens to you?
My problem was that the default maximum message size was configured to be too small
on the server and this resulted in the same forced connection closing. There is a default
maximum message size to avoid DOS attacks...

If you are using a WCF client to connect to the service, enable service trace logging in your client application with the following config:
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Error"
propagateActivity="true">
<listeners>
<add name="sdt"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "ErrorTrace.svclog"
/>
</listeners>
</source>
</sources>
</system.diagnostics>
Download the windows sdk and you have a nice trace viewer for these log files. It helps you get to the bottom of errors in WCF communication.

Using cross platform communication sometimes it happens (once happened to my code) that the exception thrown is not the real description of what is happening inside.
One cause of this exception is that your response time is a little lesser than time required by the webservice method to complete. So try to increase the timeout in your app.config.
If it doesn't work there could be two possible problems in your case.
If SSL is used then there is problem with SSL certificate validity.
There are some invalid characters used in XML for example your platform doesn't support Unicode characters and there is some un-supported character used in XML.
But I hope just increasing the timeout will fix this.

I did get similar error and cause was exception in XML serialization. Mostly if xmlserializer tries to read some property and that get method raises an exception due to some database connection already closed or any resources not available.
Have you tried to log exceptions in error event inside global.asax?
Sometimes if global.asax does not raise error event, then only way to log error through response filter. You can add custom response filter in the web.config, in which you will be able to analyze how much XML was correctly serialized and where it might be failing.
http://msdn.microsoft.com/en-us/library/aa479332.aspx
http://www.raboof.com/projects/elmah/

Intermediate "An existing connection was forcibly closed by the remote host" from only one destination sounds like a networking issue to me.
Try getting logs from the server you try to access and from the involved firewalls of both locations.
You may run Fiddler or NetMon / WireShark / Ethereal to diagnose further.

Connection close happen for any circumstance. Make sure the timeout is abundant on the server and the client, make sure there is no recursion in the data you are returning. Circular reference. Serialization is important in this case because the thing is being serialized when returned.
Do a WCF tracer and check the answer there. Any fault in the server will close the connection. If the server requires username, make sure those are correct. Take care of the SSL error. use WCF client to test the service.

This may be a shot in the dark but here is my theory:
The first error is happening on the web service side with a poor exception being thrown, maybe some invalid data is being passing into the service? This could return the error regarding the XML being malformed. I would do several test cases to see what data is being passed into the service and what causes the issue.
The second error I have seen before in a certain circumstance regarding a web service exception being thrown and a try catch wrapped around a using statement for the service. This combination of logic caused an early exit that wasnt cleaned up.

try to check the existing protocols in your last company and compare them with your current company,I mean TCP/Ip,...

Check the app pool recycling configuration in IIS. I have seen this error, for example, when the "Private Memory Limit" is set to a value (say 100mb) and then the w3wp process exceeds this limit which will cause the app pool to be recycled.
This normally isn't a problem since any existing connections are given time to complete and new connections will be processed by the newly spun-up app pool.
If all the connections are not closed within the shutdown time limit though (normally 90 seconds) then they are killed by IIS and the client may raise the "An existing connection was forcibly closed" error.

Crashing the AzureDiagnostics agent on compute emulator

We've recently started running into a problem with the Windows Azure Computer Emulator in which the DiagnosticsAgent crashes on role startup, however we still get all our traces to the compute emulator console. I'm not 100% I've even really got an issue, but I don't want there to be a lingering bug that causes me trouble when I deploy to the cloud. Has anyone seen error messaging similar to the below, and if so, what were you able to do about it? I've not been able to find any info on SO or the remainder of the interwebs.
Thanks in advance.
[Diagnostics]: Error starting diagnostics:
System.Net.WebException: The server committed a protocol violation. Section=ResponseStatusLine
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitor.ValidateEndpointValid(CloudStorageAccount acct, Action`1 error)
at Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitor.StartWithExplicitConfiguration(DiagnosticMonitorStartupInfo startupInfo, DiagnosticMonitorConfiguration initialConfiguration)
at Microsoft.WindowsAzure.Plugins.Diagnostics.DiagnosticsAgentManager.<StartAgent>b__0()

Enyim Memcached Client does not write / read data

I've installed memcached on Windows as a service, listening on the default port 11211. I know this works, because I can telnet to the server and carry out get / set commands without any problems.
I've then downloaded the Enyim Memcached client (Enyim.Caching.dll, version 2.7) and written a simple test program:
var mcc = new MemcachedClientConfiguration();
mcc.AddServer("127.0.0.1:11211");
mcc.SocketPool.ReceiveTimeout = new TimeSpan(0, 0, 10);
mcc.SocketPool.ConnectionTimeout = new TimeSpan(0, 0, 10);
mcc.SocketPool.DeadTimeout = new TimeSpan(0, 0, 20);
using (MemcachedClient client = new MemcachedClient(mcc))
{
client.Store(StoreMode.Set, "enyimtest", "test value");
Console.WriteLine(client.Get<string>("enyimtest"));
}
I know this connects to my server correctly, as calling the stats command in telnet shows an increase in the number of connections. However, it doesn't call get or set, as the cmd_get and cmd_set stats counters remain constant. The call to client.Get returns null.
The program does not error in any way. Does anyone know what could prevent the Enyim client from working in this situation?
EDIT:
Looks like this is caused by a timeout. Afer configuring log4net to capture the client's logging output, I found it contained the following (in addition to other stack trace items):
2010-12-17 14:26:37,579 [1] ERROR Enyim.Caching.Memcached.MemcachedNode [(null)] - System.IO.IOException: Failed to read from the socket '172.23.0.100:11211'. Error: TimedOut
2010-12-17 14:26:37,626 [1] WARN Enyim.Caching.Memcached.MemcachedNode.InternalPoolImpl [(null)] - Marking node 172.23.0.100:11211 as dead
I still don't understand why it is timing out though?

After an hour or so of playing around, I've found the answer. I used Wireshark to look at the network traffic to and from the server. I noticed that when using the Enyim client, the messages looked nothing like those when using telnet. In particular, I couldn't read the protocol commands going across the wire when using the Enyim client.
Therefore, I concluded that the Enyim client was using a different protocol.
A second protocol was added to the memcached server in version 1.4, which is the binary protocol. Prior to that, only the text protocol was supported. The latest Windows binary I can find for memcached is the one from Jellycan, and it is only version 1.2.6.
The Enyim client is configured to use the Binary protocol by default, which was just ignored by my server as it couldn't be understood.
I added the following line to my test program, and things started working immediately:
mcc.Protocol = MemcachedProtocol.Text;

I ran into the same issue above. I too struggled to find a newer version of memcached for Windows, but did find one eventually.
I've put links to the latest binaries along with other useful resources here.