We recently added MongoCk to our Spring 5 app (using the Spring runner), but are having some issues during our deploys. Our final step in the deploy process is a health check where the deployment server checks a health page every 5s for 5 minutes. Once it gets the correct response the deployment is considered successful and it finishes.
The issue is that MongoCk seems to only start the migration around 30s after the application context loads, resulting in the health check passing and the migration possibly failing after the service was "successfully" launched.
Using a standalone runner might solve this, but we really like the availability of other beans during the changelogs. So is there a way to enforce the changelogs to be processed as part of loading the application context? Or where is this delay coming from, and how can we reduce it?
You don't provide much information, but you are saying that Mongock starts 30 secs after the application context is loaded. That could be happening for two reasons:
The most likely possibility is that you are using runner-type ApplicationRunner(by default). This means that Spring decides when to run it after the entire context is loaded. From what you are saying runner-type InitializingBean is a better fit for you .
Please try this:
mongock:
runner-type: InitializingBean
You have multiple instances fighting for the lock. There is nothing we can do about it, this process is optimised(Although we are improving even more). However, as said, I believe the issue is related with the runner-type
I've successfully followed the Daemons and Service Guide - Creating XPC Services tutorial, along with the SandboxedFetch sample code and have a working Client / Service setup that is using the new NSXPCConnection class.
What still isn't entirely clear to me is how to properly self-terminate the service application once it has finished its job. I recognize that in many cases, the service is expected to remain alive, but in the use-case I have in mind, the service will be used to only to do some processing that I'd otherwise not perform in the main application. Once that processing is finished, there's no reason for the service application to remain. If the client needs another service at a later date, it can just re-create a new one.
Since the service is a lightweight, non-nibbed, NSApplication, I was trying to self-terminate it by calling invalidate from inside applicationWillTerminate, but that triggers an EXC_BAD_ACCESS exception almost every time. Calling invalidate on the service's [NSXPCListener serviceListener] generates slightly less reliable crashes, but it still crashes.
Calling invalidate from within the client application on its NSXPCConnection also generates an EXC_BAD_ACCESS exception almost every time.
So I'm curious what the correct sequence of steps is to cleanly shutdown the XPC service and then quit the service application. Ideally, the service would self-terminate after it has made its last XPC call to the client.
Attached is a small screenshot of what one of the exception's stacktrace looks like. (Yes, that's a webview that's loading in the service. Once the webview has finished loading, I want the service to self-terminate)
My first reaction is that you should not bother to terminate. When memory pressure occurs and your service is idle, launchd will kill your service. Exiting probably isn't in anyone's best interest because your service will take time to launch again. Don't terminate and you won't have to figure out why your attempt crashes.
But if for some reason you are determined to terminate, don't try so hard. Just do whatever you need to do to clean up (flush buffers, close network connections gracefully so the server doesn't suffer, whatever) and call exit. Although you seem to be using NSApplication, your service is not an application in any sense that the user cares about and there is no compelling reason to act like one in this respect. The host application needs to be able to cope with your service crashing anyway, so your deliberately exiting unceremoniously is just fine.
By the way, using NSApplication in an XPC service probably isn't the best idea because there's no supported way to declare that you want that. This might help explain why it isn't working as well as you'd like, though this paragraph should not be construed as a proper analysis of the crash. :-)
I have created apps in the past that would have web pages that would call the persistence layer to get some query results or to insert, delete, etc against a db. However, nothing was left running in the background except for the persistence layer. Now I need to develop an app that has an process that is always running in the background, which is waiting for messages to come thru a zeromq messaging system (cannot change this at this point). I am a little lost as to how to setup the object so that it can always be running and yet I can control or query the results from the object.
Is there any tutorial/examples that covers this configuration?
Thanks,
You could use some kind of timer, to start a method every second to look at a specific ressource and process the input taken from that.
If you use Spring than you could have a look at the #Scheduled annotation.
If your input is some kind of java method invokation, than have a look at the java.util.concurrent Package, and concurrent programming at all. -- But be aware of the fact, that there are some restictions one creating own Threads in an EJB environment.
In Visual Studio 2010, I have a number of unit tests. When I run multiple tests at one time using test lists, I sometimes reveive the following error for one or more of the tests:
The agent process was stopped while
the test was running.
It is never the same test failing, and if I try to run the test again, it succeeds.
I found this bug report on Connect, which seems to be the same problem, but it does not offer a solution.
Has anyone else seen this behaviour ? How I can avoid it ?
Edit
I am still experiencing this bug, and so is many of my colleagues on the same software/hardware setup. I have evaluated the answers so far, but they don't resolve the problem. I am starting a bounty for a solution to this problem.
This message is caused by an exception on a thread different from the executing test thread. All answers so far boil down to this simple explanation. It is a known bug in Visual Studio not to display any sensible information in that case.
Visual Studio’s test runner totally chokes if a thread other than the executing test thread throws an exception: It gets swallowed and there’s no output, no chance to intercept and debug and no nothing except a burned-down smoldering mess that was supposed to be your unit test.
I've just experienced the similar problem: some tests fail and they are different in different test runs. I don't know exactly the reason why it happens, but it began to occur when I added a finalizer to one of my classes. When I disable the finalizer - the problem disappears. When I turn the finalizer on - the problem comes back.
Right now I don't know how to overcome this.
I was having this problem, and it turned out to be a problem in my code which the Test Framework wasn't catching properly. A little accidental refactoring had left me with this code:
public void GetThingy()
{
this.GetThingy();
}
This is of course an infinite recursion, and caused a StackOverflowException (I guess). What this caused was the dreaded: "The agent process was stopped while the test was running."
A quick code inspection showed me the problem, and my tests are now running fine. Hope this helps - might be worth inspecting the code looking for issues, or maybe extracting a bit into a console app and checking it works properly there.
I was able to find the source of my problem by looking in the test result file (/TestResults/*.trx) It provided the full details of the exception that occurred in the background thread, and once I resolved that exception the "agent processed stopped..." error went away.
In my case I was unintentionally launching the GUI in my unit test, which eventually caused a System.ComponentModel.InvalidAsynchronousStateException to be thrown.
So my .trx file contained:
<RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
<Text>One of the background threads threw exception:
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method. The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
</RunInfo>
This didn't provide any information on what test caused the error, but it did show me where the exception was, which was very useful.
This message is typically generated when the test process crashes and can happen when there is an unhandled exception on a background thread, a stack overflow occurs, or an explicit call to Process.GetCurrentProcess().Kill() or Environment.Exit. Another possible cause is an access violation in unmanaged code.
Something no one has mentioned is that there may be additional information in the event log. Usually you will not get much information on why the test crashed in the results, however in the event of an unhandled exception on a background thread, then the test framework writes details to the Application event log with source VSTTExecution. If there is no information written to the event log then it is likely one of the other causes listed above.
I encountered the same Problem and solved it while Removing
Environment.Exit(0);
So i am pretty sure, that this error occurs while your test or method under test, is causing the executing process to terminate.
In my case the solution was resolved by checking the Output Window.
'QTAgent32.exe' (Managed
(v4.0.30319)): Loaded
'C:\TestResults\bdewey_XXXXXX072
2011-01-11
17_00_40\Out\MyCode.dll',
Symbols loaded. E, 9024, 9,
2011/01/11, 17:00:46.827,
XXXXX072\QTAgent32.exe, Unhandled
Exception Caught, reporting through
Watson: [Exception message]
In my case I had a FileSystemWatcher that was throwing an error on a seperate thread.
Thanks for posting the question. I just ran into this problem and figured out a cause that you may be running into.
An asynchronous exception may have
occurred
During my test setup, I create an object that queues a worker thread in the thread pool. If I run through debugging fast enough my code passes.
If the worker thread kicks off and has an error BEFORE the test setup completes, then I get a result of Aborted with no reasoning.
If the worker thread kicks off and has an error AFTER the test has begun, then I get a result of : Error - The agent process was stopped while the test was running.
Important to note: this is a component that I use throughout several of my tests. If the test framework encounters too many of these errors it aborts the rest of the tests.
Hope this helps
I added try/catch blocks to the descructor ~ClassName(){} that were defined in any class involved in my tests. This fixed the problem for me.
~MyClass()
{
try
{
// Some Code
}
catch (Exception e)
{
// Log the exception so it's not totally hidden
// Console.WriteLine(e.ToString());
}
}
For finding out where the exception was thrown click on the hyperlink "Test Run Error" next to the exclamation icon in the Test Results window. A window with the stack trace is opened.
This helps a lot to track down the error!
I had the same problem and it was caused by a finalizer for an unmanaged resource (a file writer that was not getting disposed properly for some reason).
After wrapping the finalizer code in a try-catch that swallows the exception, the problem disappeared. I don't recommend swallowing exceptions like that, so it would obviously be wise to find out why the exception is occurring in the first place.
I have had this happening on the odd occasion, and the culprit almost always turns out to be threading.
Strangely enough all the tests would work fine on the development machines, then randomly fail on the build servers.
On closer inspection it turned out that although the tests were being listed as passed on the dev boxes, there were exceptions being thrown. The exceptions were being thrown on a seperate thread which didn't get picked up as an error.
The exception details were being logged against the test trace, so we were able to identify which code/tests needed to be modified.
Hope this helps someone.
In my case I had some unit-tests for a WCF-service. This WCF service was starting up 2 timers.
Those timers caused side effects.
--> I disable these timers by default and everything is fine!
BTW: I use WCFMock to fake the WCF service, so I have "real" unit tests around my WCF service
This error was caused by a Finalizer for me as well.
The Finalizer was actaully calling some DB code which wasn't mocked out. Took me a while to find it as it wasn't a class I wrote and the reference to it was burred quite a few classes deep.
I have run into a similar problem where a test is failing in TestInitialize and is also running code from a ddl from another of my projects. I get the error message as described above and if I try to debug the test, the test is just aborted without any exception details.
I suspect that the problem may be that the dlls from my other project are from a Visual Studio 2012 project and I am running my tests in a VS2010 project, and/or possibly that the UnitTestFramwork dll versions from the 2 projects are mismatched.
The problem can also be triggered by an Exception or Stackoverflow in Constructor of a TestClass.
As this error can have many different causes, I'd like to add another one for completeness of this thread.
If all your tests are aborting as described by the OP, the cause might be a wrong project configuration. In my case the target framework was set to .NET Framework 3.5. Setting it to a higher version through the project properties page (tab Application) resolved the issue.
I was able to determine what was causing my issue by looking in the Windows Logs > Application log entries within the Windows Event Viewer. Look for entries at the time the test bombed-out. I had an Error entry similar to below:
QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
at XXX.YYY.ZZZ.cs:line 660
at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180
It was indeed a null reference exception within a method called from a class finalizer.
For anyone happening upon this old question and wondering what's being thrown from their thread(s), here's a tip. Using Task.Run (as opposed to, say, Thread.Start) will report child thread exceptions much more reliably. In short, instead of this:
Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();
Do this:
Task t = Task.Run(() => FunctionThatThrows());
t.Wait();
And your error logs should be much more useful.
We are running our Junit 4 test suite against Weblogic 9 in front of an Oracle 10 database (using Hudson as a continuous integration server) and occasionally we will get an ORA-12519 crash during script teardown. However, the error is very intermittent:
It usually happens for the same Test class
It doesn't always happen for the same test cases (sometimes they pass)
It doesn't happen for the same number of test cases (anywhere from 3-9)
Sometimes it doesn't happen at all, everything passes
While I can't guarantee this doesn't happen locally (when running against the same database, of course), I have run the same suite of class multiple times with no issues.
Any ideas?
Don't know if this will be everybody's answer, but after some digging, here's what we came up with.
The error is obviously caused by the fact that the listener was not accepting connections, but why would we get that error when other tests could connect fine (we could also connect no problem through sqlplus)? The key to the issue wasn't that we couldn't connect, but that it was intermittent
After some investigation, we found that there was some static data created during the class setup that would keep open connections for the life of the test class, creating new ones as it went. Now, even though all of the resources were properly released when this class went out of scope (via a finally{} block, of course), there were some cases during the run when this class would swallow up all available connections (okay, bad practice alert - this was unit test code that connected directly rather than using a pool, so the same problem could not happen in production).
The fix was to not make that class static and run in the class setup, but instead use it in the per method setUp and tearDown methods.
So if you get this error in your own apps, slap a profiler on that bad boy and see if you might have a connection leak. Hope that helps.
Another solution I have found to a similar error but the same error message is to increase the number of service handlers found. (My instance of this error was caused by too many connections in the Weblogic Portal Connection pools.)
Run SQL*Plus and login as SYSTEM. You should know what password you’ve used during the installation of Oracle DB XE.
Run the command alter system set processes=150 scope=spfile; in SQL*Plus OR any SQL friendly IDE.
VERY IMPORTANT: Restart the database, to make the change effective in the SPFILE.
From here:
http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/
I also had the same problem, I searched for the answers many places. I got many similar answers to change the number of process/service handlers. But I thought, what if I forgot to reset it back?
Then I tried using Thread.sleep() method after each of my connection.close();.
I don't know how, but it's working at least for me.
If any one wants to try it out and figure out how it's working then please go ahead. I would also like to know it as I am a beginner in programming world.
I had this problem in a unit test which opened a lot of connections to the DB via a connection pool and then "stopped" the connection pool (ManagedDataSource actually) to release the connections at the end of the each test. I always ran out of connections at some point in the suite of tests.
Added a Thread.sleep(500) in the teardown() of my tests and this resolved the issue. I think that what was happening was that the connection pool stop() releases the active connections in another thread so that if the main thread keeps running tests the cleanup thread(s) got so far behind that the Oracle server ran out of connections. Adding the sleep allows the background threads to release the pooled connections.
This is much less of an issue in the real world because the DB servers are much bigger and there is a healthy mix of operations (not just endless DB connect/disconnect operations).
I had the similar issue. It happened every time when I run a pack of database (Spring JDBC) tests with SpringJUnit4ClassRunner, so I resolved the issue putting #DirtiesContext annotation for each test in order to cleanup the application context and release all resources thus each test could run with a new initalization of the application context.