Is there a way to stop a remote connection?
In more detail if a WCF connection is created using the ChannelFactory
var aChannelFactory = new ChannelFactory<ISomeService>(aBinding, aEndpoint);
and the connection is used via GSM, it makes sense to enlarge timeouts so that
aChannelFactory.CreateChannel();
has the possibility to connect to the remote site.
Now the problem is that a user may have the wish to stop the creation of a connection (Abort a getting connencted window, only use offline part of a programm).
But how is this possible?
The CreateChannel-call is synchronous.
Even if it is wrapped in a thread, nowadays Thread.Abort should not be used.
Is there any way to stop the creation of a channel automatically?
Or must it be "faked" to a user, so that the connection still is running until its timeout (or success) even is user decided to work temporarely offline?
As Grant Thomas stated it is not necessary to abort the connection.
Related
I'm trying to make a stunnel clone in C# just for fun. The main loop goes something like this (ignore the catch-everything-and-do-nothing try-catches just for now)
ServicePointManager.ServerCertificateValidationCallback = Validator;
TcpListener a = new TcpListener (9999);
a.Start ();
while (true) {
Console.Error.WriteLine ("Spinning...");
try {
TcpClient remote = new TcpClient ("XXX.XX.XXX.XXX", 2376);
SslStream ssl = new SslStream(remote.GetStream(), false, new RemoteCertificateValidationCallback(Validator));
ssl.AuthenticateAsClient("mirai.ca");
TcpClient user = a.AcceptTcpClient ();
new Thread (new ThreadStart(() => {
Thread.CurrentThread.IsBackground = true;
try{
forward(user.GetStream(), ssl); //forward is a blocking function I wrote
}catch{}
})).Start ();
} catch {
Thread.Sleep (1000);
}
}
I found that if I do the remote SSL connection, as I did, before waiting for the user, then when the user connects the SSL is already set up (this is for tunneling HTTP so latency is pretty important). On the other hand, my server closes long-inactive connections, so if no new connection happens in, say, 5 minutes, everything locks up.
What is the best way?
Also, I observe my program generating as much as 200 threads, which of course means that context-switching overhead is pretty big and sometimes results in the whole thing just blocking for seconds, even with just one user tunneling through the program. My forward function goes, in a gist, like
new Thread(new ThreadStart(()=>in.CopyTo(out))).Start();
out.CopyTo(in);
of course with lots of error handling to prevent broken connections from holding up forever. This seems to stall a lot though. I can't figure how to use asynchronous methods like BeginRead which should help according to google.
For any kind of proxy server (including an stunnel clone), opening the backend connection after you accept the frontend connection is clearly much simpler to implement.
If you pre-open backend connections in anticipation of receiving frontend connections, you can certainly save an RTT (which is good for latency), but you have to deal with the issue you hinted at: the backend will close idle connections. At any time that you receive a frontend connections, you run the risk that the backend connection that you are about to associate with this frontend connection and which has been opened some time ago is too old to use and may be closed by the backend. You will have to manage a pool of currently open backend connections and periodically close and refresh them when they become idle for too long. There is even a race condition where if the backend decided the connection has been idle too long and decides to close it but the proxy server receives a new frontend connection at the same time, the frontend may decide to forward a request through the backend connection while the backend is closing this connection. That means that you must be able to know a priori how long backend connections can be idle for before the backend will close them (you must know what the timeout values that are configured on the backend are set to) so you can give them up just before the backend will decide they are too old.
So in summary: pre-opening backend connections will save an RTT versus opening them only on demand, but it is a lot of work, including subtle connection pool management that it quite tough to implement bug-free. Up to you to judge if the extra complexity is worth it.
By the way, concerning your comment about handling several hundred simultaneous connections, I recommend implementing such an I/O-bound program as a proxy server based around an event loop instead of based around threads. Basically, you use non-blocking sockets and process events in a single thread (e.g. "this socket has new data waiting to be forwarded to the other side") instead of spawning a thread for each connection (which can get expensive both in thread creation and context switches). In order to scale such an event-based model to multiple CPU cores, you can start a small number of parallel threads of processes (more or less one per CPU core) which each handle many hundreds (or thousands) of simultaneous connections.
I use RabbitMQ.Client (runtime version v2.0.50727, version 2.8.1.0) with C# .NET application.
I create connection like this:
using (IConnection connection = _factory.CreateConnection())
{
using (IModel channel = connection.CreateModel())
{
// code...
}
}
If I close the application properly, it simply closes the channel and connection. But if application is closed incorrectly (e.g. pressing restart button on PC), it is not. I would like to ensure that all unnecessary connections (from previous sessions or even other applications, if by mistake other instance of the application is running somewhere else) are closed before I start my application.
I know I may use heart beats but it is possible that my application requires really much time to start doing anything (many hours of opened connection and not being used). So I think heartbeat is not the best thing.
How can I close all opened connections for RMQ? (Or, even better, all opened connections, with the exception for one given IP)?
Regards!
I encountered the same problem as you. I tried a lot of methods to close those connections.
Those methods, some are works some are only part works. Maybe you can have a try.
Use rabbitmqctl command to delete the queues then use RMQ's management website close the connections. It means current opened queues will expire after 1 second(1000 miliseconds). This way all queues are deleted. Then you can close connections.
Command:
rabbitmqctl set_policy expiry ".*" '{"expires":1000}' --apply-to queues
Queue Time-To-Live policy--> https://www.rabbitmq.com/ttl.html
This method works partly.
After searching, got the idea that reason might be:
Your producer waiting the return ACK back, it won't be destroyed untill you send ACK to acknowledge the job has finished.
Abrupt way. Works. RMQ save connections information in its DB menisa.
Step1: Stop rabbitmq-server first, and kill rabbitmq thread by 'ps aux | grep rabbitmq' to find its pid then kill all rabbitmq thread.
Find RMQ DB mensia location
(1). $> cd /var/lib/rabbitmq/
Step2: rename mensia file to another name to "delete"
(2). $> mv mensia mensia-bak
Step3: restart rabbitmq-server
The third methods works for me now. It can close all open connections.
Sounds like Heartbeats is your best solution. I added heartbeats to my RabbitMQ apps for the same reason (ungraceful shutdowns). It shouldn't matter that there is a long gap of time between messages, heartbeat will just verify that the connection is still open on both sides.
I had the same problem when I open worker in console and than stop it with ctrl+c. After than process is closed but connection is still there and it's visible in admin panel.
One solution is to close connection in RabbitMQ Admin panel
or you can found the process and kill it manual sudo kill -9 pid
or when you open an connection set HEARTBEAT. Read [Dead TCP Connections]
I face the following problem :
Connection Pool has reached the maximum number of connections
I followed all the recommendations. the problem is n't like before but it happens rarely !!
I use the Using statement with all my connections and Readers .
Lately i face the following error , and i had to reset the iis to fix my problem.
Connection Pool has reached the maximum number of connections. at IBM.Data.Informix.IfxConnectionPool.ReportOpenTimeOut()
at IBM.Data.Informix.IfxConnectionPool.Open(IfxConnection connection)
at IBM.Data.Informix.IfxConnPoolManager.Open(IfxConnection connection)
at IBM.Data.Informix.IfxConnection.Open()
at DB_Connection_s.DB_Connection.GetUserSystems(String emp_num)
Now I read about this method ClearAllPools() .but i don't know when to use this method .and if this considered as a good solution to prevent the have to reset the iis to fix the request time out problem ??
You can call ClearAllPools() when you dont have any active connection.
also check out http://www.codeproject.com/Articles/46267/Connection-Pooling-in-ASP-NET
Ensure that your application closes all database connections correctly and consistently.
Ensure that the database is online.
Increase the connection timeout.
The error pattern indicates that connections are "leaked" over a long period. To fix this problem, ensure that your application closes all database connections correctly and consistently.
The exception does not indicate that the database is offline. The exception indicates a connection pool problem.
If i have a client that is connected to a server and if the server crashes, how can i determine, form my client, if the connection is off ? the idea is that if in my client's while i await to read a line from my server ( String a = sr.ReadLine(); ) and while the client is waiting to recieve that line , the server crashes , how do i close that thread that contains my while ?
Many have told me that in that while(alive) { .. } I should just change the alive value to true , but if my program is currently awaiting for a line to read, it won't get to exit the while because it will be trapped at sr.ReadLine() .
I was thinking that if i can't send a line to the server i should just close the client thread with .abort() . Any Ideas ?
Have a TimeOut parameter in ReadLine method which takes a TimeSpan value and times out after that interval if the response is not received..
public string ReadLine(TimeSpan timeout)
{
// ..your logic.
)
For an example check these SO posts -
Implementing a timeout on a function returning a value
Implement C# Generic Timeout
Is the server app your own, or something off the shelf?
If it's yours, send a "heart beat" every couple of seconds to let the clients know that the connection and service are still alive. (This is a bit more reliable than just seeing if the connection is closed since it may be possible for the connection to remain open while the server app is locked.)
That the server crashes has nothing to do with your clients. There are several external factors that can make the connection go down: The client is one of them, internet/lan problems is another one.
It doesn't matter why something fails, the server should handle it anyway. Servers going down will make your users scream ;)
Regarding multi threading, I suggest that you look at the BeginXXX/EndXXX asynchronous methods. They give you much more power and a more robust solution.
Try to avoid any strategy that relies on thread abort(). If you cannot avoid it, make sure you understand the idiom for that mechanism, which involves having a separate appdomain and catching ThreadAbortException
If the server crashes I imagine you will have more problems than just fixing a while loop. Your program may enter an unstable state for other reasons. State should not be overlooked. That being said, a nice "server timed out" message may suffice. You could take it a step further and ping, then give a slightly more advanced message "server appears to be down".
We have a TIBCO EMS solution that uses built-in server failover in a 2-4 server environment. If the TIBCO admins fail-over services from one EMS server to another, connections are supposed to be transfered to the new server automatically at the EMS service level. For our C# applications using the EMS service, this is not happening - our user connections are not being transfered to the new server after failover and we're not sure why.
Our application connection to EMS at startup only so if the TIBCO admins failover after users have started our application, they users need to restart the app in order to reconnect to the new server (our EMS connection uses a server string including all 4 production EMS servers - if the first attempt fails, it moves to the next server in the string and tries again).
I'm looking for an automated approach that will attempt to reconnect to EMS periodically if it detects that the connection is dead but I'm not sure how best to do that.
Any ideas? We are using TIBCO.EMS.dll version 4.4.2 and .Net 2.x (SmartClient app)
Any help would be appreciated.
First off, yes, I am answering my own question. Its important to note, however, that without ajmastrean, I would be nowhere. thank you so much!
ONE:
ConnectionFactory.SetReconnAttemptCount, SetReconnAttemptDelay, SetReconnAttemptTimeout should be set appropriately. I think the default values re-try too quickly (on the order of 1/2 second between retries). Our EMS servers can take a long time to failover because of network storage, etc - so 5 retries at 1/2s intervals is nowhere near long enough.
TWO:
I believe its important to enable the client-server and server-client heartbeats. Wasn't able to verify but without those in place, the client might not get the notification that the server is offline or switching in failover mode. This, of course, is a server side setting for EMS.
THREE:
you can watch for failover event by setting Tibems.SetExceptionOnFTSwitch(true); and then wiring up a exception event handler. When in a single-server environment, you will see a "Connection has been terminated" message. However, if you are in a fault-tolerant multi-server environment, you will see this: "Connection has performed fault-tolerant switch to ". You don't strictly need this notification, but it can be useful (especially in testing).
FOUR:
Apparently not clear in the EMS documentation, connection reconnect will NOT work in a single-server environment. You need to be in a multi-server, fault tolerant environment. There is a trick, however. You can put the same server in the connection list twice - strange I know, but it works and it enables the built-in reconnect logic to work.
some code:
private void initEMS()
{
Tibems.SetExceptionOnFTSwitch(true);
_ConnectionFactory = new TIBCO.EMS.TopicConnectionFactory(<server>);
_ConnectionFactory.SetReconnAttemptCount(30); // 30retries
_ConnectionFactory.SetReconnAttemptDelay(120000); // 2minutes
_ConnectionFactory.SetReconnAttemptTimeout(2000); // 2seconds
_Connection = _ConnectionFactory.CreateTopicConnectionM(<username>, <password>);
_Connection.ExceptionHandler += new EMSExceptionHandler(_Connection_ExceptionHandler);
}
private void _Connection_ExceptionHandler(object sender, EMSExceptionEventArgs args)
{
EMSException e = args.Exception;
// args.Exception = "Connection has been terminated" -- single server failure
// args.Exception = "Connection has performed fault-tolerant switch to <server url>" -- fault-tolerant multi-server
MessageBox.Show(e.ToString());
}
This post should sum up my current comments and explain my approach in more detail...
The TIBCO 'ConnectionFactory' and 'Connection' types are heavyweight, thread-safe types. TIBCO suggests that you maintain the use of one ConnectionFactory (per server configured factory) and one Connection per factory.
The server also appears to be responsible for in-place 'Connection' failover and re-connection, so let's confirm it's doing its job and then lean on that feature.
Creating a client side solution is going to be slightly more involved than fixing a server or client setup problem. All sessions you have created from a failed connection need to be re-created (not to mention producers, consumers, and destinations). There are no "reconnect" or "refresh" methods on either type. The sessions do not maintain a reference to their parent connection either.
You will have to manage a lookup of connection/session objects and go nuts re-initializing everyone! or implement some sort of session failure event handler that can get the new connection and reconnect them.
So, for now, let's dig in and see if the client is setup to receive failover notification (tib ems users guide pg 292). And make sure the raised exception is caught, contains the failover URL, and is being handled properly.
Client applications may receive notification of a failover by setting the tibco.tibjms.ft.switch.exception system property
Perhaps the library needs that to work?