Background: My application is used to execute tests using Selenium RC servers, and occasionally I'm running into a problem when my call to a Selenium command doesn't return the response from the RC server - it then ends up blocking the thread that is executing the test.
Sample Code:
Private Delegate Function DoCommand_Delegate(ByVal command As String, ByVal args() As String) As String
...
asyncCommand = New DoCommand_Delegate(AddressOf server.DoCommand)
asyncResult = asyncCommand.BeginInvoke(command, args, Nothing, Nothing)
Try
... (I have it use the AsyncWaitHandle to wait for periods of 10 seconds up to two minutes. At the end of each period it runs some checks for common problems that block Selenium from returning a response (modal dialogs) - I don't think that part is relevant to this question, it's just necessary.)
Finally
result = asyncCommand.EndInvoke(asyncResult)
...
At the time EndInvoke is called, the worker delegate has either already finished or needs to be aborted. Most of the time it already has a response so it works just fine, but on rare occasion Selenium RC's DoCommand doesn't return, so the thread sits there locked.
Finally, my question: is there a resource-friendly way to abort the executing delegate, or do I need to convert it to use a manually controlled thread that can be aborted and disposed?
Note: This is not a question regarding Selenium, just proper multithreading.
Note 2: I've considered doing the following in the Finally before calling EndInvoke:
If Not asyncResult.IsCompleted Then asyncResult.AsyncWaitHandle.Close()
... But I don't know if that would actually work correctly, or what damage that could cause.
There is no way to do the following at the same time:
Abort/kill a thread non-cooperatively
Without destroying all state associated with it (AppDomain/process)
Implies: Either terminate cooperatively (not possible here) or kill the process (AppDomain not enough because native state is involved) or don't kill the thread.
You could just not kill the thread and leave it there hanging. The rest of your program (the remaining tests) can continue to execute.
I'd not be happy to see this in production but for a test suite this could be ok (assuming the hang cannot be fixed).
Why can't a thread be aborted? This has been covered a number of times on Stack Overflow already.
Related
What I am doing is writing a WPF application to work with our device. The application writes some commands to the device and reads command's response from it. I got pinvoke declarations from pinvoke.net website for CreateFile, WriteFile, ReadFile, etc.
I made a function doing following things, CreateFile(with flag FILE_FLAG_OVERLAPPED
) to open device, WriteFile to send command, ReadFile to read response, WaitForSingleObject and GetOverlappedResult to capture timeout exception if device doesn't respond, and CloseHandle to close device.
This function always worked fine if I called it in UI thread. But I wanted to call it in background thread to keep UI active. So I created a thread in Window_Loaded method(Work is my function's name).
t = new Thread(Work);
t.Start();
Then ReadFile, WaitForSingleObject and GetOverlappedResult group may met error, these three functions returned success and GetOverlappedResult could capture correct read length returned from device. But no actual data read from device filled in the byte array buffer passed to ReadFile function. The failure rate was about 50%.
If I waited thread t to finish, then it always worked fine again.
t = new Thread(Work);
t.Start();
t.join();
Of cause UI would also hang in this situation.
I searched this problem but no exact same question was found. I tried to set background thread's apartment state to STA or MTA explicitly, but it didn't work.
t = new Thread(Work);
t.SetApartmentState(ApartmentState.STA);
t.Start();
It really confuses me. Please help me if you have any idea. Thank you for your reading.
I couldn't find the root cause. But I bypassed it by rewriting read process in C++ function and calling my C++ function with pInvoke.
when SetScriptTimeout should be used and please provide me any example.
I know the defn
Sets the amount of time to wait for an asynchronous script to finish execution before throwing an error. If the timeout is negative, then the script will be allowed to run indefinitely.
but not sure what it does exactly.
You've got two answers already, neither of which I find explain clearly the point of setting a script timeout.
First, it is important the script timeout affects only JavaScript code executed with executeAsyncScript and nothing else. In particular, executeScript is not affected by it.
So why do you want to set a timeout for executeAsyncScript? Chandan Nayak correctly explained that the default timeout is 0s so you have to change this timeout if you want to use executeAsyncScript with asynchronous scripts that actually perform some work. But why not just set it to -1 and be done with it? After all, if you set it to -1 then you turn off the timeout. So you won't get any timeouts anymore. Mission accomplished, right? Nope.
What you want to do is set the timeout to a value that allows the code you use with executeAsyncScript to perform it works while at the same time detect when a script has gone rogue. For instance, if from experience you know that a script you pass to executeAsyncScript is going to be done in 2 seconds or less (except perhaps in extremely unusual circumstances), then you set the timeout to 2 seconds so that if there is a bug somewhere and the code never terminates, you get a timeout after 2 seconds. Otherwise, Selenium will happily wait forever for the script to complete.
From WebDriver documentation:
setScriptTimeout(long time, java.util.concurrent.TimeUnit unit)
Sets the amount of time to wait for an asynchronous script to finish execution before throwing an error. This works only for Assync scripts (executeAsyncScript)
Let's run a simple javascript: (Do not set setScriptTimeout ) - Now this shall execute without throwing any issue.
((JavascriptExecutor) driver).executeScript("alert('hello world');");
Lets run a simple Assync Script: ( Do not set setScriptTimeout) - This shall fail with error - "Timed out waiting for async script result after 0ms"
((JavascriptExecutor) driver).executeAsyncScript("window.setTimeout(arguments[arguments.length - 1], 500);");
To resolve the issue: setScriptTimeout to 1 Second:
driver.manage().timeouts().setScriptTimeout(1, TimeUnit.SECONDS);
And then run the same Assync Script mentioned above and it shall execute without any error.
Reason:
The default timeout for a script to be executed is 0ms. In most cases, including the examples below, one must set the script timeout WebDriver.Timeouts.setScriptTimeout(long, java.util.concurrent.TimeUnit) beforehand to a value sufficiently large enough
More Reference Links:
When should setScriptTimeout be used?
WebDriver executeAsyncScript vs executeScript
WebDriver Doc
Web application automation is dependent on many factors like browser, network speed, embedded scripting etc. To write robust code for running in all environments we need to inserts wait for WebElements before performing any operation on that.
WebDriver wait (synchronization) can be obtained either by using support.ui or driver().manage().timeouts()
If we use driver.manage().timeouts(), a common practice to achieve synchronization is to use JavaScript via JavascriptExecutor which in turn provide two methods for script execution:
executeAsyncScript -> This method doesn't block the execution of next line of code...till execution of this method is completed. This method will execute as well as next line of code will be executed...asynchronously. (without blocking each other)
executeScript -> This method will block the execution till it's execution is completed and then it moves to next line of code. In short your automation code will halt till the Javascript is executed via this method.
Now since executeAsyncScript method doesn't block the execution of next line of code, it might be beneficial to use driver.manage().timeouts().setScriptTimeout(30,SECONDS);
so that our code can wait for specified amount of time for an asynchronous script to finish execution before throwing an error.
Second question on here...
Basically I am having a problem with a Stackoverflow exception that is thrown in my program, and I literally have no idea on how to locate the cause..
I have a program which has a plugin system, and it's a program that utilizes TCP in order to send and receive data; Server-> Client. I am making a remote console plugin, and the problem occurs when I do the command 'tree'; the filesystem entries listing command. For the first few seconds everything goes alright; the commands are being outputted (sent from Client to server). The receiving packets event isn't thread safe, so in the API I've provided an invocation function (to invoke methods on the UI thread). So therefore on output, it will do the following:
Public Sub ClientReadPacket(Sender As IClient, Pipename As String, Values As Object())
Select Case DirectCast(Values(1), ConsoleCommands)
Case ConsoleCommands.Output
ServerGUI.Send(Sub() ConsoleOutput.AppendText(Values(2) & Environment.NewLine))
End Select
End Sub
As you can see, the ServerGUI is an interface that I have provided for plugin development. And in the actual program - in the class that implements the GUI interface, I get a stackoverflow exception right here:
Private Sub ISend(del As System.Threading.SendOrPostCallback) Implements IGUI.Send
UIThread.Send(del, Nothing)
End Sub ' The break point is here; I assume that means that the exception ocurs in the line above.
The UIThread object is a synchronizationcontext of the main thread.
http://i.gyazo.com/870d9667f2272969b650cea836adca50.png
Update: So far I've narrowed it down to the following; it must be causing stackoverflow exception when calling SynchronizationContext.Send() too often, and the same happens when I rather use Invoke() in the plugin, it also gives a Stackoverflow exception.
I tried using asyncoperation, and this does not crash, but due to the fact that it's solely asynchronous is a problem, because my program becomes unresponsive when using Post(), because it continuously Posts (due to the fact that it will manage the next packet before the asyncoperation has posted.
I am trying to write a control panel to
Inform about certain KPIS
Enable the user to init certain requests / jobs by pressing a button that then runs a stored proc on the DB or sets a specific setting etc
So far, so good, except I would like to run some bigger jobs where the length of time that the job is running for is unknown and could run over both the script timeout period AND the time the user is willing to wait for a response.
What I want is a "fire and forget" process so the user hits the button and even if they kill the page or turn off their phone they know the job has been initiated and WILL complete.
I was looking into C# BeginExecuteNonQuery which is an async call to the query so the proc is fired but the control doesn't have to wait for a response from it to carry on. However I don't know what happens when the page/app that fired it is shut.
Also I was thinking of some sort of Ajax command that fires the code in a page behind the scenes so the user doesn't know about it running but then again I believe if the user shuts the page down the script will die and the command will die on the server as well.
The only way for certain I know of is a "queue" table where jobs are inserted into this table then an MS Agent job comes along every minute or two checking for new inserts and then runs the code if there is any. That way it is all on the DB and only a DB crash will destroy it. It won't help with multiple jobs waiting to be run concurrently that both take a long time but it's the only thing I can be sure of that will ensure the code is run at all.
Any ideas?
Any language is okay.
Since web browsers are unconnected, requests from them always take the full amount of time. The governing factor isn't what the browser does, but how long the web site itself will allow an action to continue.
IIS (and in general, web servers) have a timeout period for requests, where if the work being done takes simply too long, the request is terminated. This would involve abruptly stopping whatever is taking so long, such as a database call, running code, and so on.
Simply making your long-running actions asynchronous may seem like a good idea, however I would recommend against that. The reason is that in ASP and ASP.Net, asynchronously-called code still consumes a thread in a way that blocks other legitimate request from getting through (in some cases you can end up consuming two threads!). This could have performance implications in non-obvious ways. It's better to just increase the timeout and allow the synchronously blocking task to complete. There's nothing special you have to do to make such a request complete fully, it will occur even if the sender closes his browser or turns off his phone immediately after (presuming the entire request was received).
If you're still concerned about making certain work finish, no matter what is going on with the web request, then it's probably better to create an out-of-process server/service that does the work and to which such tasks can be handed off. Your web site then invokes a method that, inside the service, starts its own async thread to do the work and then immediately returns. Perhaps it also returns a request ID, so that the web page can check on the status of the requested work later through other methods.
You may use asynchronous method and call the query from this method.
Your simple method can be changed in to a asynch method in the following manner.
Consider that you have a Test method to be called asynchronously -
Class AsynchDemo
{
public string TestMethod(out int threadId)
{
//call your query here
}
//create a asynch handler delegate:
public delegate string AsyncMethodCaller(out int threadId);
}
In your main program /or where you have to call the Test Method:
public static void Main()
{
// The asynchronous method puts the thread id here.
int threadId;
// Create an instance of the test class.
AsyncDemo ad = new AsyncDemo();
// Create the delegate.
AsyncMethodCaller caller = new AsyncMethodCaller(ad.TestMethod);
// Initiate the asychronous call.
IAsyncResult result = caller.BeginInvoke(
out threadId, null, null);
// Call EndInvoke to wait for the asynchronous call to complete,
// and to retrieve the results.
string returnValue = caller.EndInvoke(out threadId, result);
Console.WriteLine("The call executed on thread {0}, with return value \"{1}\".",
threadId, returnValue);
}
From my experience a Classic ASP or ASP.NET page will run until complete, even if the client disconnects, unless you have something in place for checking that the client is still connected and do something if they are not, or a timeout is reached.
However, it would probably be better practice to run these sorts of jobs as scheduled tasks.
On submitting your web page could record in a database that the task needs to be run and then when the scheduled task runs it checks for this and starts the job.
Many web hosts and/or web control panels allow you to create scheduled tasks that call a URL on schedule.
Alternately if you have direct access to the web server you could create a scheduled task on the server to call a URL on schedule.
Or, if ASP.NET, you can put some code in global.asax to run on a schedule. Be aware though, if your website is set to stop after a certain period of inactivity then this will not work unlesss there is frequent continuous activity.
I would like my node.js tests to ensure that, once the test is over and test.finish() or similar is called, that there is no more code waiting to be run. No more I/O waiting to finish, no more timers waiting to fire, etc. etc.
Is this possible in node.js?
When using nodeunit each test function keeps running until test.done() has been called. Every test function needs to call this. This way you can make sure your callbacks have been executed. I also like to use async module to clean up my code(callbacks) a bit.
Are you using test.expect() at the beginning of each test and test.done() at the end of each one? Think of them like begin and end braces.
I wrote my own, which essentially spins up a node instance for each test. If your test leaves a callback dangling, node just won't exit, and the whole test suite hangs instead of exiting early with success (which would be bad!)