Need tips on how to program this!

  • Thread starter Thread starter Jeff
  • Start date Start date
J

Jeff

IDE: VS .NET 2003
OS: XP pro sp2

I'm developing a server application, clients will connect to it over the net
and start different tasks....

When people sends a command to the program, the command is first placed into
ThreadPool for await processing...

Here is the what I'm having problem with:
I want to implement some kind of a timeout functionality, so if a task takes
too long to perform the user will be notified that a timeout occured on the
server... I'm not sure how to implement timeout, because I must time the
task from the server receive the task and put it into the threadpool and
await processing... while it is in the threadpool it's waiting to be
processed, and as far as I know, if a timeout happens while it's still in
the threadpool it will not be triggered because it isn't assgined processor
power...

Please give me some tips on how to implement this functionality

Jeff
 
Here is one way I might do it....

When the command is recieved, the command is put into an object where the
command, the IP or other info about the sender of the command is passed into
the constructor of the object, and inside the constructor there is code to
store the time of command reception, and the other info into variables then
store it in the pool.

When its time to execute the command, get the object and check to see if it
is too old to process and if so, send a message to the sender that the
server was too busy to execute the command and to try again.

Once you are past that point, you have this command object reception time,
that you can work with to perhaps utilize some sort of user defined event
that aborts the current command and sends a message that the command has
timed out, and then dispose of the command object or whatever you wish to do
with it.

Also, on the internet, I remember something about packets already having a
built in lifetime, you might be able to utilize this functionality rather
than re-inventing the wheel.
 
What will be "timing out"? The job itself or timeout waiting for the job to
start (i.e. very busy). Are you saying that you want a job to only run for
max time of 10 minutes or something? Will the jobs be Batch Files or EXEs
run with the Process class or predefined Methodswith args on your server?
 
Jeff said:
IDE: VS .NET 2003
OS: XP pro sp2

I'm developing a server application, clients will connect to it over the net
and start different tasks....
Click to expand...

Why would you use the ThreadPool to execute the tasks? especially if you
expect them to be long-lived you should just start a new Thread().

If it is because you wish to impose a limit on the amount of running
jobs, put them in a producer-consumer Queue and use a semaphore to limit
the amount of started threads.

How are you going to "timeout"? there really is no reliable way to stop
a Thread in .NET, both Thread.Interrupt and Thread.Abort may block
indefinatly, and they both have "issues". If your jobs are started in
separate Process'es, then you can abort them when their timeout expires
by killing the process, but that may also be unacceptable to you.

You could have something like:

- a "timeout-thread", which loops:
- waits for the closest timeout to expire
- try to kill the corresponding thread/process if it's still around
- an "enqueue-thread", which loops:
- accept jobs from network
- enqueue job
- a "dequeue-thread", which loops:
- pop from the queue
- [optional: limit running jobs] wait for a semapore
- starts a new thread
- [optional: limit running jobs] a "monitor-thread", which loops:
- waits for any of the started threads to expire
- signal the semaphore
When people sends a command to the program, the command is first placed into
ThreadPool for await processing...
Click to expand...

Don't use the ThreadPool for running longer jobs, it's a resource which
others might use. Use a new Thread or Process, which *fails* instead of
*blocking* if that resource (Threads, Processess) is exhausted.
task from the server receive the task and put it into the threadpool and
Click to expand...

To monitor the complete time from accept to execution, you need to
time-stamp the incoming jobs when they are received. You also need to
traverse the Queue at regular intervals, expiring jobs that are
time-out'et before they have even begun.
Please give me some tips on how to implement this functionality
Click to expand...

Thats my $.02
 
When the command is recieved, the command is put into an object where the
command, the IP or other info about the sender of the command is passed
into the constructor of the object, and inside the constructor there is
code to store the time of command reception, and the other info into
variables then store it in the pool.

When its time to execute the command, get the object and check to see if
it is too old to process
Click to expand...

But that might still be way after the timeout value has expired ... wouldn't
it be better to have the queuing object itself have a timer and when it runs
out, remove itself from the queue and return timeout failure return code to
the client? Or alternatively a 'timeout-checking' thread.
 
Back
Top