I have "Run each query in its own process" option turned on (default value), but it seems that the process is being reused between query runs (LINQPad.UserQuery.exe keeps running).
Is there a way to avoid this reuse? I need a fresh process every time (due to JVM usage).
Obvious way is
Environment.Exit(0);
but it results in unpleasant "Query ended unexpectedly" message.
Try Util.NewProcess = true:
Util.NewProcess = true;
Process.GetCurrentProcess().Id.Dump();
Also you can try option from menu: 'Query' -> 'Cancel All Threads and Reset' (also available via shortcut Shift+Control+F5)
The option "Run each query in its own process" instructs LINQPad to use process isolation rather than AppDomain isolation. It will still re-use the process if you re-run the same query.
The option you want is "Always use fresh application domains". Set this to true, and you'll get a fresh process/AppDomain with each execution. Or, as the Guru suggested, set Util.NewProcess in your query. This forces the next execution to use a fresh process/domain.
Related
I am running a C# application, and during run-time I get the following error:
The CLR has been unable to transition from COM context 0x20e480 to COM context 0x20e5f0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
Can anyone please help me out with the problem here?
Thanks a lot.
The main thread of your program has been busy executing code for a minute. It is not taking care of its normal duties, pumping the message loop. That's illegal when you use COM servers in a worker thread: calls to their methods cannot be dispatched until your main thread goes idle again.
It should be readily visible, your UI should be dead as a door nail. Windows should have replaced your main window with a ghost that displays "Not Responding". Closing the window won't work, no click events have any effect.
Whatever your main thread is doing should be done by a worker thread instead. The BackgroundWorker class is good for that, you'll find many usage help in the MSDN Library article for it. Use Debug + Break All, Debug + Windows + Threads if you have no idea what the main thread is doing.
One more possible cause: be sure to install service pack 1 if you are using the RTM version of VS2005.
To find which operation is blocking the context switch and causing the contextSwitchDeadlock MDA to be displayed, you can use the following steps. Note that I will be referring to Visual Studio 2012.
Reproduce the error. This could involve some trial and error.
Click 'OK' rather than 'Continue' in the Managed Debugging assistant which is displayed.
Ensure that the Debug Location toolbar is active by right clicking on the toolbar docking region and selecting 'Debug Location'. You should see a drop down list labelled 'Thread' in the toolbar if it is active.
The selected item in the Thread drop down list should be a thread other than the main thread as it will be a background thread that is complaining that the main thread is hogging all of the attention. Select the main thread in the drop down list.
You should now see the code that is blocking the context switch in the code editor.
Assuming that you decide against moving the resource intensive operation off your main thread - take a look at some of the other answers and comments here before you do - you have the following options to disable the Managed Debugging Assistants.
Within the Visual Studio Debugger
You can disable an MDA directly in the MDA dialog that is
displayed when the error occurs by unchecking 'Break when this
exception type is thrown'.
With Exception Settings dialog using the instructions below from MSDN.
...on the Debug menu, click Exceptions. (If the Debug menu does not contain an Exceptions command, click Customize on the Tools menu to add it.) In the Exceptions dialog box, expand the Managed Debugging Assistants list, and then clear the Thrown check box for the individual MDA.
Outside the Visual Studio Debugger
Registry Key (Machine Wide, All MDAs affected)
Environment Variable (Machine Wide, MDAs can be specified)
Application Configuration Settings (Application scope, MDAs can be specified)
Note: One of the first two options must be set to 1 for the third to have any effect.
In my case, the problem was a call to ObjectContext.SaveChanges() in the Entity Framework within a console application. With the MTAThreadAttribute applied to the Main() method the ContextSwitchDeadlock exception was no longer raised. I am unfortunately unsure of the full affects of this change.
This message indicates that some code of yours is trying to switch threads, and the target thread is busy. For example, a background thread trying to dispatch a call to the UI thread to update the UI, while the UI is running a tight loop for a while.
To actually figure out what's going on you need to break into the debugger and look at all the threads and what they are doing.
In some cases :
Debug -> Exceptions -> Managed Debug Assistants
and unchecking the ContextSwitchDeadlock item.
Simply select Exceptions from the Debug menu in the visual studio 2005 window , the Edxception Dialog box wil popup , select the Managed Debugging Assistants Exception Node , then select ContextSwitchDeadlock and remove the select from Thrown column . this will stop the vs from throwing the ContextSwitchDeadlock exception.
Hope this helps..
I ran into this issue when I was trying to figure out why my OracleDataReader was throwing an exception. I thought it was because it was getting assigned null because the exception was related to a parameter that was `null. So I did:
while (dr.Read())
{
while (dr != null) // <-- added this line
{
...
Turned out the dr was NEVER null and so the loop just went on and on until this message arrived, and on and on some more because you can click "Continue" to keep it going until you run out of memory (don't do this - click "OK" instead). So moral of the story, look for memory leaks that are streaming data from the database into memory in loops to infinity. The error is actually trying to warn you of a bad scenario. Best to heed it.
This error came up for me numerous times, and I traced it down to an iteration in DataGridViewRow, in which I set the checkbox value to true. Since I was running in debug mode, I had the option to continue, so I was able to do just this.
I hope this helps someone.
Finally, I found a working solution for my vb.net Windows Application Form
Application.DoEvents()
Statement somewhere within the loop.
Reference: https://earlybites.wordpress.com/2012/04/10/resolution-context-switch-deadlock-was-detected/
Assuming you are using Visual Studio, you can click Ctrl+Alt+E in the current project and exceptions window will display with select
Managed Debugging Assistants you should uncheck the "ContextSwitchDeadlock" option. then build a current project.
I'm new to Jitterbit and I'm working in Jitterbit Studio 5.6.0.1. In our deployed project we have 4 consequential operations and the first one is scheduled. What I want to do is to put a condition on the first scheduled operation that it should not run until all operations from the previous run are finished. I want to avoid running the operation twice. Any help?
Thanks
First off, I would suggest upgrading your studio to 8.12 (current version). Aside from that, if you add a script before the operation that you want to check, you can use something along these lines:
isInQueue=GetOperationQueue("<TAG>Operations/Your_Operation</TAG>");
isRunning=isInQueue[0][1];
if(isRunning==1 && isRunning!=Null(),
"Do Something";
);
That's just a very basic idea of how you can handle this. In my situation, I have an operation that has just a script like this in it, that either direct to a script to run if not already running, or direct to a dead-end, if it needs to skip this scheduled instance.
I have a VB application which is scheduled. It focuses on some cmd windows and performs sendkey actions. This works fine when I have the RDP session open, it's only when I disconnect (not logoff) that the issue occurs. (This task is running on a virtualised server).
When I open the RDP session again after the task has ran, the application has thrown an error regarding the login permissions. I presume this is because the user is locked and therefore can't perform the actions?
I need to find a way around this, any help is much appreciated!
Don't use SendKeys.
Instead, if you have a program running in a command prompt, make sure the VB.NET program is the one to open it (or them) with Process.Start, and set the RedirectStandardInput property of the ProcessStartInfo object you pass to True. Then pass commands into the process's StandardInput property as though writing to a file.
This will avoid any focus-change problems, any problems to do with locked screen sessions, most if not all potential problems with integrity levels, most if not all problems with timing, and probably some other stuff I'm not thinking of.
My program checks if there is a new version of itself. If yes it would exit and start an updater that replaces it and then restarts.
My problem is that I haven't found any info on how to make process start right after closing the actual program.
Any suggestions?
Thanks in advance
I intended to add a comment, but I'm too low in points here. The updater itself should probably contain a check to determine whether your application is running an instance, and it should contain a timeout loop that performs this check and factor the timeout following it's startup state. That way you can awaken it, and close your application. The updater should just determine your application is not running, compare versions perform the intended update operation.
a possible solution would also be to create a task via tash sceduler or cron job, starting an out of process application, like CMD.exe.. which brings me to my original comment-question: in regards to what Operating System(s) and Platform(s) is your program intended for?
I'm writing a WLST script to deploy some WAR's and an EAR. However, intermittently, the script will time out because it can't seem to get an edit lock (this script is part of a chain of many other scripts). I was wondering, is there a way to override or stop any current locks on the server? This is only a temporary solution, but in the interest of time, it will do for now.
Thanks.
You could try setting a wait period and timeout:
startEdit([waitTimeInMillis], [timeoutInMillis], [exclusive]).
Are other scripts erroring out, leaving the session locked? You could try adding exception handling around those. Also, if you have 'Automatically acquire lock" enabled in the Admin Console and you use the admin console sometimes it can cause problems if you are running scripts at the same time, even though you are not making "lock-requiring" changes.
Also, are you using the same user for the chained scripts?
Within WLST, you can pass a number as a parameter to gain an exclusive lock. This allows the script to grab a different lock than the regular one that's used whenever an administrator locks from the console. It also prevents two instances of the same script from stepping on each other.
However, this creates complex change merge scenarios that are best avoided (by processes).
Oracle's documentation on configuration locks can be found here.
Alternatively, if you want the script to temporarily relieve any existing locks regardless of the pending changes, you may as well disable change management from the console, minimizing the inconvenience caused.
WLST also contains the cancelEdit command that you could run before you startEdit. Hope one of these options pan out!
To take the configuration change lock from another administrator:
If another administrator already has the configuration lock, the following message appears: Another user already owns the lock. You will need to either wait for the lock to be released, or take the lock.
Locate the Change Center in the upper left corner of the
Administration Console.
Click Take Lock & Edit.
Make your configuration changes.
In the Change Center, click Activate Changes. Not all changes take
effect immediately. Some require a restart (see Use the Change
Center).
As long as you're running WLST as an administrative user, you should be able to jump into an existing edit session with the edit() command - I've done a quick test with two admin users, one in the Admin Console, and one using WLST, and it appears to work fine - I can see the changes in the Admin Console session inside the WLST interpreter.
You could put a very simple exception handler around your calls to startEdit that will log the exception's stack trace, but do nothing else. And then rely on the edit call to pop you into the change session.
Relying on that is going to be tricky though if another script has started an edit session and is expecting to be able to commit that change session itself - you'll be getting exceptions and unreliable behaviour across multiple invocations.