SO users,
I have 3 threads running simultaneously at any given time, trouble is after thread 1 tries to connect to a server by passing a username to it thread 2 is being invoked and by the time its thread 1's turn the server closes its connection on the code.
Is there anywhere I can implement sending username and password simultaneously with out threads interrupting each other at this time?
Thx!,
Nidhi
I very much doubt that it's genuinely thread contention which is the problem here.
Threads timeslice very quickly, and the server would have to have a ridiculously short timeout for your diagnosis to be correct.
My guess is there's something different wrong with your code, but we can't really tell what it is without seeing some code.
threads typically swap on the order of milliseconds, so i don't think thats whats causing your program to disconnect.
That said, you can implement locks/mutexes to ensure that critical code is executed without other threads executing their code, and even use thread prioritization to ensure one thread gets priority over others - but you cannot force a thread not to yield, the operating system can decide you've run long enough and force you to yield regardless. Besides, the behavior your looking for is more or less explicitly prevented in all modern schedules to prevent starvation of other processes.
It looks like you're trying to multiplex multiple data streams on one socket. So you may be running into a thread switching problem while waiting for the server, but if that's the case you're probably doing something like this, which is an inappropriate way to multithread.
void Task(int type)
{
// Authenticate
// Send Data
// Disconnect
}
// Connect
Thread.Start(Task(1));
Thread.Start(Task(2));
Thread.Start(Task(3));
If you've got threads 1, 2, and 3 doing work on the server in tandem you've got a few ways to do it:
1.) Do your work threaded with different connections
void Task(int type)
{
// Connect
// Authenticate
// Send Data
// Disconnect
}
Thread.Start(Task(1));
Thread.Start(Task(2));
Thread.Start(Task(3));
2.) Do your work singlethreaded with one connection
void Task(int type)
{
// Send Data
}
// Connect
// Authenticate
Task(1);
Task(2);
Task(3);
// Disconnect
3.) Use multiple connections
Related
We have a Windows service that calls a 3rd party method that can hang when improperly configured by the end user, which is difficult to test for beforehand. We're handling this risk by calling the method in a Task with a timeout:
private int? FooWithTimeout()
{
var timeout = TimeSpan.FromMinutes(1);
var task = Task.Run(Foo);
if (!task.Wait(timeout))
{
Log("Foo timed out...");
return null;
}
if (task.IsFaulted)
{
Log("Foo threw an exception...");
return null;
}
return task.Result;
}
The 3rd party method blocks forever waiting for input from a resource that cannot respond. It does not support cancellation in any way, shape, or form, nor does it have a built-in timeout. Our concern is that as the service runs these tasks will continue blocking and slowly accumulate, eventually consuming a large amount of resources.
Is that a valid concern? Do we need to abort/dispose the tasks in some way? If so, what is the correct way to do so?
Addendum: The 3rd party in question is Crystal Reports. It hangs when asked to print to a printer that requires some sort of additional input from the user (for example, Microsoft XPS Document Writer will prompt you for where to save the file if you print to it). And by hang, I mean it attempts to show a user prompt to get the additional input, but it's in a Windows Service so nobody ever sees the user prompt and it waits forever for a human being to tell it how to print. We allow end users to configure which printer the service attempts to print to, and there isn't really any way to tell if a given printer requires additional input short of attempting to print to it.
Our concern is that as the service runs these tasks will continue blocking and slowly accumulate
This is a valid concern. You can reduce the consequences of that by starting those tasks on a special thread-pool that uses small stacks. That way there is less memory usage. But it's not a complete fix. If you app must function for a long time (not a GUI app intended for a few hours of use) then this solution will prove unacceptable because eventually the app will suffer from resource exhaustion.
.NET has no way to terminate an uncooperative thread. You need to run these actions in their own processes. You can then terminate those processes safely.
Using AppDomains might be safe as well but it's less certain. It's possible that per-process state is being corrupted when an AppDomain and threads in it are aborted. Also, not all thread can be aborted. In particular IO operations.
Using separate processes is also not a guarantee that no state corruption will result from termination. But in practice most corruptible state live in memory. Process termination likely clears all inconsistent state.
One approach could be to create separate thread which would monitor for any newly created windows - if any new window is created - thread would try to forcefully to close them.
Enumerate windows:
How to enumerate all windows belonging to a particular process using .NET?
And close non wanted windows:
How to use WM_Close in C#?
May be will not work, just a proposal... :-)
I have following scenario:
C# application (.net 4.0/4.5), with 5-6 different threads. Every thread has a different task, which is launched every x seconds (ranging from 5 to 300).
Each task has following steps:
Fetch items from Sql Server
Convert items in Json
Send data to webserver
Wait for reply from server.
Since this tasks can fail at some point (internet problems, timeout, etc) what is best solution in .NET world?
I thought about following solutions:
Spawn new thread every x seconds (if there is not another thread of this type in execution)
Spawn one thread for each type of task and loop steps every x seconds (to understand the way to manage exceptions)
Which would be more secure and robust? Application will run on unattended systems, so it should be able to remain in execution regardless of any possible exception.
Threads are pretty expensive to create. The first option isn't a great one. If the cycle of "do stuff" is pretty brief (between the pauses), you might consider using the ThreadPool or the TPL. If the threads are mostly busy, or the work takes any appreciable time, then dedicated workers are more appropriate.
As for exceptions: don't let exceptions escape workers. You must catch them. If all that means is that you give up and retry in a few seconds, that is probably fine.
You could have modeled the whole thing using a producer consumer pattern approach. You have a producer who puts the new task description in the queue and you can have multiple consumers (4 or 5 threads) who process from the queue. The number of consumers or the processing thread could vary depending on the load, length of the queue.
Each task involves reading from DB, converting the format, sending to web server and then process the response from web server. I assume each task would do all these steps.
In case of exceptions for an item in the queue, you could potentially mark the queue item as failed and schedule it for a retry later.
We are just starting to use RabbitMQ with C#. My current plan is to configure in the database the number and kind of consumers to run on a given server. We have an existing windows service and when that starts I want to spawn all of the RabbitMQ consumers. My question is what is the best way to spwan these from a windows service?
My current plan is to read the configuration out of the database and spawn a long running task for each consumer.
var t = new Task(() =>
{
var instance = LoadConsumerClass(consumerEnum, consumerName);
instance.StartConsuming();//blocking call
}, TaskCreationOptions.LongRunning);
t.Start();
Is this better or worse than creating a thread for each consumer?
var messageConsumer = LoadConsumerClass(consumerEnum, consumerName);
var thread = new Thread(messageConsumer.StartConsuming);
I'm hoping that more than a few others have already tried what I'm doing and can provide me with some ideas for what worked well and what didn't.
In EasyNetQ we have a single dispatcher thread for all consumers on a single connection. We also provide a facility to to return a Task from the message handler, so it's easy to do async IO if you want to make a database call, go to the file system, or make a web service request.
Having said that it's perfectly legitimate to have each consumer consuming on a different thread. I guess it depends on your message throughput, how many consumers you have and the nature of your message handlers.
I'd stick with Tasks as they give you more features and generally allow for less boilerplate code.
And, If I understand your code correctly, you'd be sharing a channel (IModel) in second case. This might cause troubles as the default IModel implementation is not thread safe (or used to be). There're more subtle nuances regarding thread safety you'd have to watch out.
But it depends on your usage patterns. If you don't expect many messages/sec on each consumer, or if your app can handle messages fast then perhaps a single thread for all consumers will be you best option.
Task is great, but you not really going to use all the stuff it can do. The only thing you need is to do work in parallel.
I faced the same question couple of months ago, what I finished with - is a thread per computation type (per queue) which is blocking on message arrival and doesn't consume cpu when waiting for messages.
Open a new channel for each one of the threads.
As for connections - if you application is meant to deal with high load of messages, I suggest you opening connection for every X workers (figure you your X), since only one channel can send the messages through the connection, so assuming one worker is consuming large message the others are blocked on connection level waiting it to be free.
I've got an architecture that involves browsers polling via ajax every 3 seconds for updates and I'd like to change that to long-polling.
I'd like to have 1, 2.. {n} clients long-polling, waiting for updates and have something happen on the server to signal the waiting clients to return. My first thought was to use an EventWaitHandle, and I can do this easily if I just want to support 1 client. I'd just have an AutoResetEvent WaitHandle that would WaitOne to block the client, maybe with a timeout, maybe not. Either way, an AutoResetEvent will only allow me to support 1 client (since it only wakes 1 waiting thread) and I want n clients.
I'm pretty sure I need to use a ManualResetEvent WaitHandle, but I'm not sure when to call Reset after I Set it (when waking the threads). Should I simply Thread.Sleep some arbitrary amount in between the Set and Reset?
In psuedo code, the waking logic would be
get ManualResetEventWaitHandle
call Set
ensure all waiting clients have woken, while preventing new requests from blowing through
call Reset now that all waiting clients have received their updates
Its that 3rd line that i'm having a hard time with. Currently I am tossing around the idea of having a LastTxID that the client / server maintain and potentially using 2 wait handles. However, before I went crazy with this implementation I wanted to get feedback here to see how they would implement the waking logic.
Edit: assume I've got the problems associated with having max concurrent users figured out, either by tweaking IIS or hosting via WCF or some other solution. I only want to focus on the waking logic.
One idea, in pseudo code
Maintain a thread-safe list of connection id's, possibly use the session id
Give every connection its own AutoResetEventWaitHandle
In a thread safe manner, loop through those wait handles and set them when there is an update
on session end, in a thread safe manner, remove that connection / session id from the list
I'd love to get some feedback on this
con's to this approach
have to maintain a list of connections
have to generate {n} wait handles for {n} clients
A few words about an ongoing design and implementation
I send a lot of requests to the remote application (running on a different
host, of course), and the application send back data.
About client
Client is a UI that spawn a separate thread to submit and process the requests. Once it submits all the requests, it calls Wait. And the Wait will parse all events coming the app and invoke client's callbacks.
Below is the implementation of Wait.
public void Wait (uint milliseconds)
{
while(_socket.IsConnected)
{
if (_socket.Poll(milliseconds, SelectMode.SelectRead))
{
// read info of the buffer and calls registered callbacks for the client
if(_socket.IsAvailable > 0)
ProcessSocket(socket);
}
else
return; //returns after Poll has expired
}
}
The Wait is called from a separate thread, responsible for managing network connection: both inbound and outbound traffic:
_Receiver = new Thread(DoWork);
_Receiver.IsBackground = true;
_Receiver.Start(this);
This thread is created from UI component of the application.
The issue:
client sometimes sees delays in callbacks even though main application has sent the data on time. Notably, one the message in Poll was delayed until I client disconnected, and internally I called:
_socket.Shutdown(SocketShutdown.Both);
I think something funky is happening in the Poll
Any suggestions on how to fix the issue or an alternative workaround?
Thanks
please let me know if anything is unclear
A couple of things. First, in your example, is there a difference between "_socket" and "socket"? Second, you are using the System.Net.Sockets.Socket class, right? I don't see IsConnected or IsAvailable properties on that class in the MSDN documentation for any .NET version going back to 1.1. I assume these are both typing mistakes, right?
Have you tried putting an "else" clause on the "IsAvailable > 0" test and writing a message to the Console/Output window, e.g.,
if (_socket.IsAvailable > 0) {
ProcessSocket(socket);
} else {
Console.WriteLine("Poll() returned true but there is no data");
}
This might give you an idea of what might be going on in the larger context of your program.
Aside from that, I'm not a big fan of polling sockets for data. As an alternative, is there a reason not to use the asynchronous Begin/EndReceive functions on the socket? I think it'd be straightforward to convert to the asynchronous model given the fact that you're already using a separate thread to send and receive your data. Here is an example from MSDN. Additionally, I've added the typical implementation that I use of this mechanism to this SO post.
What thread is calling the Wait() method? If you're just throwing it into the UI threadpool, that may be why you experience delays sometimes. If this is your problem, then either use the system threadpool, create a new one just for the networking parts of your application, or spawn a dedicated thread for it.
Beyond this, it's hard to help you much without seeing more code.