Loki-Afro
commented
6 years ago @garydgregory does it work with mongodb 3.4? When your java app hangs: take a threaddump to see where
sudo -u <java-user> jstack -l <pid> Closed garydgregory closed 5 years ago
Loki-Afro
commented
6 years ago @garydgregory does it work with mongodb 3.4? When your java app hangs: take a threaddump to see where
sudo -u <java-user> jstack -l <pid> 
garydgregory
commented
6 years ago It works fine with de.flapdoodle.embed.mongo 2.0.0. This is what I found when I logged on to our build machine: It appears that MongoDB crashed:
Problem signature:
Problem Event Name: APPCRASH
Application Name: extract-d045e9c1-a7e6-40c7-8751-06168ae79f11extractmongod.exe
Application Version: 3.6.0.0
Application Timestamp: 5a219657
Fault Module Name: ntdll.dll
Fault Module Version: 6.3.9600.18821
Fault Module Timestamp: 59ba86db
Exception Code: c000007b
Exception Offset: 00000000000ece70
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 1033
Additional Information 1: ac05
Additional Information 2: ac0507478d1c5bd693cfc4fe3987e900
Additional Information 3: ac05
Additional Information 4: ac0507478d1c5bd693cfc4fe3987e900
Please see screenshots:
Any thoughts on debugging this?
I wonder if your plugin could log the exact command it uses to start and manage Mongo. This would let user try to reproduce issues from the command line outside of a Maven build.
Loki-Afro
commented
6 years ago @garydgregory
Seems to be related to this issue: https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo/issues/167#issuecomment-358646897
Thats why I asked: does it work with mongodb 3.4? To change the version embed mongo is using see here https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo#main-versions
garydgregory
commented
6 years ago I did not understand you question before, sorry about that. Testing plugin 2.0.1 with 3.4 ... I also see here https://www.mongodb.com/download-center?jmp=nav#community that the latest version is 3.6.2.
garydgregory
commented
6 years ago Yes, it works with Version.Main.V3_4. Now what?
garydgregory
commented
6 years ago Previously with 3.6.0 I also found this:
23-Jan-2018 16:18:26 | Exception in thread "Thread-116" java.lang.IllegalStateException: Shutdown in progress
-- | --
23-Jan-2018 16:18:26 | at java.lang.ApplicationShutdownHooks.add(ApplicationShutdownHooks.java:66)
23-Jan-2018 16:18:26 | at java.lang.Runtime.addShutdownHook(Runtime.java:211)
23-Jan-2018 16:18:26 | at de.flapdoodle.embed.process.io.file.FileCleaner.forceDeleteOnExit(FileCleaner.java:52)
23-Jan-2018 16:18:26 | at de.flapdoodle.embed.process.io.file.Files.forceDelete(Files.java:125)
23-Jan-2018 16:18:26 | at de.flapdoodle.embed.process.extract.ExtractedFileSets.delete(ExtractedFileSets.java:77)
23-Jan-2018 16:18:26 | at de.flapdoodle.embed.process.store.ExtractedArtifactStore.removeFileSet(ExtractedArtifactStore.java:147)
23-Jan-2018 16:18:26 | at de.flapdoodle.embed.process.runtime.Executable.stop(Executable.java:77)
23-Jan-2018 16:18:26 | at de.flapdoodle.embed.process.runtime.Executable$JobKiller.run(Executable.java:90)
23-Jan-2018 16:18:26 | at java.lang.Thread.run(Thread.java:748)
Then this ticket is an duplicate of gh-167 :)
As a temporary workaround stay with mongodb 3.4 and embed mongo 2.0.1
I'll try to push a branch where this is fixed today, would be great if you try it out then, but closing this as duplicate of gh-167
garydgregory
commented
6 years ago OK, I'll watch https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo/issues/167, keep me posted :-)
garydgregory
commented
6 years ago @Loki-Afro I am running the windows_include_dlls build with mvn clean install now but I already see failures:
[INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ de.flapdoodle.embed.mongo ---
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running de.flapdoodle.embed.mongo.config.DownloadConfigBuilderTest
Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.346 sec <<< FAILURE! - in de.flapdoodle.embed.mongo.config.DownloadConfigBuilderTest
artifactStorePathChosenProperly[1](de.flapdoodle.embed.mongo.config.DownloadConfigBuilderTest) Time elapsed: 0.042 sec <<< FAILURE!
org.junit.ComparisonFailure: Environment variable overrides default when supplied expected:<[/some/explicit/]directory> but was:<[C:\some\explicit\]directory>
at de.flapdoodle.embed.mongo.config.DownloadConfigBuilderTest.artifactStorePathChosenProperly(DownloadConfigBuilderTest.java:58)
artifactStorePathChosenProperly[2](de.flapdoodle.embed.mongo.config.DownloadConfigBuilderTest) Time elapsed: 0.003 sec <<< FAILURE!
org.junit.ComparisonFailure: Environment variable overrides default when supplied expected:<[/another/explicit/]directory> but was:<[C:\another\explicit\]directory>
at de.flapdoodle.embed.mongo.config.DownloadConfigBuilderTest.artifactStorePathChosenProperly(DownloadConfigBuilderTest.java:58)
Running de.flapdoodle.embed.mongo.distribution.VersionsTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec - in de.flapdoodle.embed.mongo.distribution.VersionsTest
Running de.flapdoodle.embed.mongo.doc.HowToDocTest
[main] ERROR de.flapdoodle.embed.process.runtime.Starter - prepare executable
java.nio.file.NoSuchFileException: C:\Users\ggregory\.embedmongo\extracted\Windows-B64--2.0.7-rc1\ssleay32.dll
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:99)
at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278)
at java.nio.file.Files.copy(Files.java:1274)
at de.flapdoodle.embed.process.extract.ExtractedFileSets.copy(ExtractedFileSets.java:62)
at de.flapdoodle.embed.process.store.ExtractedArtifactStore.extractFileSet(ExtractedArtifactStore.java:110)
at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:57)
at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:49)
at de.flapdoodle.embed.mongo.doc.HowToDocTest.testDefaultOutputToNone(HowToDocTest.java:367)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at de.flapdoodle.testdoc.Recording$1.evaluate(Recording.java:77)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Download PRODUCTION:Windows:B64 START
Download PRODUCTION:Windows:B64 DownloadSize: 302871788
Download PRODUCTION:Windows:B64 0% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11% 12% 13% 14% 15% 16% 17% 18% 19% 20% 21% 22% 23% 24% 25% 26% 27% 28% 29% 30% 31% 32% 33% 34% 35% 36% 37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48% 49% 50% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60% 61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 71% 72% 73% 74% 75% 76% 77% 78% 79% 80% 81% 82% 83% 84% 85% 86% 87% 88% 89% 90% 91% 92% 93% 94% 95% 96% 97% 98% 99% 100% Download PRODUCTION:Windows:B64 downloaded with 2257kb/sI am building with:
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: 1.8.0_152, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_152\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"@Loki-Afro At this point the build has been running for 40 minutes and is doing this over and over:
[cluster-ClusterId{value='5a67ab8d0f8ce45df806c8df', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:581}
[cluster-ClusterId{value='5a67ab8d0f8ce45df806c8df', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]
[cluster-ClusterId{value='5a67ab910f8ce45df806c8e1', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:582}
[cluster-ClusterId{value='5a67ab910f8ce45df806c8e1', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]
[cluster-ClusterId{value='5a67ab020f8ce45df806c8db', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:583}
[cluster-ClusterId{value='5a67ab020f8ce45df806c8db', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]
[cluster-ClusterId{value='5a67ab050f8ce45df806c8dd', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:584}
[cluster-ClusterId{value='5a67ab050f8ce45df806c8dd', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]
[cluster-ClusterId{value='5a67ab8d0f8ce45df806c8df', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:585}
[cluster-ClusterId{value='5a67ab8d0f8ce45df806c8df', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]
[cluster-ClusterId{value='5a67ab910f8ce45df806c8e1', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:586}
[cluster-ClusterId{value='5a67ab910f8ce45df806c8e1', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]
[cluster-ClusterId{value='5a67ab020f8ce45df806c8db', description='null'}-localhost:12345] DEBUG org.mongodb.driver.connection - Closing connection connectionId{localValue:587}
[cluster-ClusterId{value='5a67ab020f8ce45df806c8db', description='null'}-localhost:12345] DEBUG org.mongodb.driver.cluster - Updating cluster description to {type=UNKNOWN, servers=[{address=localhost:12345, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: connect}}]@Loki-Afro Can you put up a 2.0.2-SNAPSHOT in a Maven repository I can just point to?
Loki-Afro
commented
6 years ago even with the shipped dlls, namely libeay32.dll and ssleay32.dll mongodb won't start because MSVCP140.dll AND VCRUNTIME140.dll .. feels like I'm back to the 90s ...
seems to be broken since mongodb 3.5.6 according to https://groups.google.com/forum/#!topic/mongodb-user/6NEWPfces6Q
Created a mongodb issue https://jira.mongodb.org/browse/SERVER-32877 ...
garydgregory
commented
6 years ago I voted for it :-)
bertramn
commented
6 years ago @Loki-Afro looks like the libeay32.dll and ssleay32.dll files in the mongo zip distros require Microsoft's Visual C++ Redistributable for Visual Studio 2015 to be installed. Probably should be raised with mongo folks as their website does not indicate that this is a pre-requisite for their zip distribution (I noted that on the mongo SERVER-32877 ticket).
Interestingly, there is also a version of the OpenSSL dlls that do not have any Visual Studio runtime dependencies - https://indy.fulgan.com/SSL. Perhaps dropping those in could do the trick as well, but that starts to get hacky.
I also noticed that flapdoodle will copy the mongo files from the zip distro around in temp folders a 2nd time after extracting. This may affect the final fix to the issue.
Loki-Afro
commented
6 years ago 3.6.3 is also affected
" zip.vim version v28
" Browsing zipfile /home/zarathustra/Downloads/mongodb-win32-x86_64-2008plus-ssl-3.6.3.zip
" Select a file with cursor and press ENTER
mongodb-win32-x86_64-2008plus-ssl-3.6.3/README
mongodb-win32-x86_64-2008plus-ssl-3.6.3/THIRD-PARTY-NOTICES
mongodb-win32-x86_64-2008plus-ssl-3.6.3/MPL-2
mongodb-win32-x86_64-2008plus-ssl-3.6.3/GNU-AGPL-3.0
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/ssleay32.dll
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/libeay32.dll
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongodump.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongorestore.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongoexport.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongoimport.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongostat.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongotop.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/bsondump.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongofiles.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongoperf.pdb
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongoperf.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongod.pdb
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongod.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongos.pdb
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongos.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongo.pdb
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/mongo.exe
mongodb-win32-x86_64-2008plus-ssl-3.6.3/bin/Install-Compass.ps1
SQB
commented
6 years ago I'm running into the same problem after upgrading WireMock to 2.15.0 and Flapdoodle from 2.0.0 to 2.0.3. Updating the Visual C++ Redistributable made no difference. Explicitly setting the Mongo version to Version.Main.V3_4 solves it for me is an acceptable workaround.
EtA: I'm on a recent JDK 8.
garydgregory
commented
6 years ago Note that on the MongoDB side, the ticket https://jira.mongodb.org/browse/SERVER-32877 has been closed as a duplicate of https://jira.mongodb.org/browse/SERVER-26028, so please go and VOTE for https://jira.mongodb.org/browse/SERVER-26028
Loki-Afro
commented
6 years ago @SQB based on https://jira.mongodb.org/browse/SERVER-32877?focusedCommentId=1826464&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1826464 installing the msi once could be a workaround too in certain situations but haven't tested that.
SQB
commented
6 years ago @Loki-Afro No joy. I even installed the Microsoft way, restarting before and after installation.
On a side note, I've also installed all Visual C++ Redistributables I could get my hands on, but that made no difference either.
As a workaround, I've hard coded to use Version.Main.V3_4, but only on my system. I can't commit and push that, since not all Windows-using cow-orkers are having the same problem, while production is *nix and thus not affected. And of course, Version.Main.PRODUCTION is preferred.
SQB
commented
6 years ago Version.LATEST_NIGHTLY works as well.
jruhe-adesso
commented
6 years ago To fix the EOF failure with 3.6.x on windows, you need following features: ONLY_WITH_SSL ONLY_WINDOWS_2008_SERVER NO_HTTP_INTERFACE_ARG
NO_HTTP_INTERFACE_ARG is required to be set for 3.6.x, but if a specific version is not defined in de.flapdoodle.embed.mongo.distribution.Version, the feature is not automatically set
Loki-Afro
commented
5 years ago Mongodb 4.0.0+ works on Windows ... guess we can't do any more here..
DmytroRybka
commented
5 years ago This issue appears again in version 2.2.0
Failing with:
[mongod error]/tmp/extract-824a5485-8061-4010-98dc-7a14be76ee7fextractmongod: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
java.io.IOException: Could not start process: <EOF>
16:14:48 at de.flapdoodle.embed.mongo.AbstractMongoProcess.onAfterProcessStart(AbstractMongoProcess.java:79)
Local build runs fine but our jenkins build fails.
lpickford-yozu
commented
5 years ago I'm having this issue running embedded mongo 2.x with spring.mongodb.embedded.version=3.6.3 defined in my spring boot projects application.properties on win10. Both mongo and java are 64bit.
Caused by: java.io.IOException: Could not start process: <EOF>
at de.flapdoodle.embed.mongo.AbstractMongoProcess.onAfterProcessStart(AbstractMongoProcess.java:79)
at de.flapdoodle.embed.process.runtime.AbstractProcess.<init>(AbstractProcess.java:116)
at de.flapdoodle.embed.mongo.AbstractMongoProcess.<init>(AbstractMongoProcess.java:53)
at de.flapdoodle.embed.mongo.MongodProcess.<init>(MongodProcess.java:50)
at de.flapdoodle.embed.mongo.MongodExecutable.start(MongodExecutable.java:44)
at de.flapdoodle.embed.mongo.MongodExecutable.start(MongodExecutable.java:34)
at de.flapdoodle.embed.process.runtime.Executable.start(Executable.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1870)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1813)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1741)
... 169 moreI don't have the option of updating mongodb to 4.x due to organisational constraints, and I can't get passed this issue to run my tests. Any advice or setup I can try?
darkknightpl
commented
5 years ago Any news with this issue? I've two tests with @SpringBootTest starting Spring context, first pass successfully, but second ends with java.io.IOException: Could not start process: <EOF>
Dependencies versions:
I'm working on Ubuntu 18.04.3
Stacktrace:
application.yml:
spring:
mongodb:
embedded:
version: 4.0.2
features: ONLY_WITH_SSL, ONLY_64BIT, NO_HTTP_INTERFACE_ARG
ispringer
commented
4 years ago I was also seeing the mysterious java.io.IOException: Could not start process: <EOF> error, with no information of why Mongo failed to start. I made the following change in de.flapdoodle.embed.mongo.AbstractMongoProcess to make it actually log stderr when the process fails, and I was then able to easily resolve the underlying issue:
diff --git a/src/main/java/de/flapdoodle/embed/mongo/AbstractMongoProcess.java b/src/main/java/de/flapdoodle/embed/mongo/AbstractMongoProcess.java
index 586e979..d232373 100644
--- a/src/main/java/de/flapdoodle/embed/mongo/AbstractMongoProcess.java
+++ b/src/main/java/de/flapdoodle/embed/mongo/AbstractMongoProcess.java
@@ -25,6 +25,7 @@ import java.net.UnknownHostException;
import java.util.HashSet;
import java.util.Set;
+import de.flapdoodle.embed.process.io.IStreamProcessor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -45,9 +46,9 @@ import de.flapdoodle.embed.process.runtime.ProcessControl;
public abstract class AbstractMongoProcess<T extends IMongoConfig, E extends Executable<T, P>, P extends IStopable> extends AbstractProcess<T, E, P> {
private static Logger logger = LoggerFactory.getLogger(AbstractMongoProcess.class);
-
+
boolean stopped=false;
-
+
public AbstractMongoProcess(Distribution distribution, T config, IRuntimeConfig runtimeConfig, E executable)
throws IOException {
super(distribution, config, runtimeConfig, executable);
@@ -59,7 +60,21 @@ public abstract class AbstractMongoProcess<T extends IMongoConfig, E extends Exe
LogWatchStreamProcessor logWatch = new LogWatchStreamProcessor(successMessage(), knownFailureMessages(),
StreamToLineProcessor.wrap(outputConfig.getOutput()));
Processors.connect(process.getReader(), logWatch);
- Processors.connect(process.getError(), StreamToLineProcessor.wrap(outputConfig.getError()));
+
+ // Track stderr, so we can log it if the process fails.
+ final StringBuilder stderr = new StringBuilder();
+ IStreamProcessor stderrProcessor = new IStreamProcessor() {
+ @Override
+ public void process(String block) {
+ stderr.append(block);
+ }
+
+ @Override
+ public void onProcessed() {
+ }
+ };
+ Processors.connect(process.getError(), stderrProcessor);
+
logWatch.waitForResult(getConfig().timeout().getStartupTimeout());
if (logWatch.isInitWithSuccess()) {
setProcessId(Mongod.getMongodProcessId(logWatch.getOutput(), -1));
@@ -76,7 +91,8 @@ public abstract class AbstractMongoProcess<T extends IMongoConfig, E extends Exe
try {
// Process could be finished with success here! In this case no need to throw an exception!
if(process.waitFor() != 0){
- throw new IOException("Could not start process: "+failureFound);
+ throw new IOException("Could not start process: " + failureFound + "\nstdout:\n" +
+ logWatch.getOutput() + "\nstderr:\n" + stderr);
}
} catch (InterruptedException e) {
throw new IOException("Could not start process: "+failureFound, e);Hopefully, this can be incorporated back into the project. I'll try to submit a PR later.
roeniss
commented
4 years ago Is this issue is resolved? I'm using 2.2.0 and sometimes(maybe 10% probability) Caused by: java.io.IOException: Could not start process: <EOF> appears then such tests are failed.
cybuch
commented
4 years ago Using mongo 3.6.4 and 2.2.0 version of embed mongo: Could not open inputStream for https://downloads.mongodb.org/win32/mongodb-win32-x86_64-3.6.4.zip. With version 3.6.5 i had simply the <EOF> error.
seta-sonnguyen
commented
3 years ago I have this issue with Win 10, Mongo 4.4.6, Spring maven app, embed mongo version 2.1.1, with below logs:
10:24:54.684 [main] ERROR d.f.e.p.runtime.AbstractProcess - failed to call onAfterProcessStart()
java.io.IOException: Could not start process:
Please help to fix this issue! Thank you
seta-sonnguyen
commented
3 years ago I can fixed the issue by:
bryancan
commented
2 years ago For me it was my McAfee. I had to turn it (McAfee) off and delete the mongo dir in my appdata/temp. Re-run then worked fine
michaelmosmann
commented
2 years ago Is this issue still a problem? There is a new release.
lukeway
commented
2 years ago Seems to work with de.flapdoodle.embed.mongo 3.2.7 and mongo 4.4.9 on Windows 10.
dvt32
commented
2 years ago Seems to work with de.flapdoodle.embed.mongo 3.2.7 and mongo 4.4.9 on Windows 10.
3.5.5 seems to also work.
And yes, it still seems to be an issue, because 3.6 versions give me EOF or inputStream errors.
michaelmosmann
commented
2 years ago @dvt32 can you use a newer version instead? or does this fail too?
Soggywaters
commented
2 years ago This is still an issue with mongo versions 3.6.0+
michaelmosmann
commented
2 years ago @Soggywaters is your issue solved with this: https://github.com/svenkubiak/embedded-mongodb/issues/4#issuecomment-1266577182
sagrawal31
commented
1 year ago For me, this is still happening on CI (Gitlab's CI) but working fine locally-
Caused by: java.lang.reflect.UndeclaredThrowableException
at org.springframework.util.ReflectionUtils.rethrowRuntimeException(ReflectionUtils.java:147)
at org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:798)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:318)
at grails.boot.GrailsApp.run(GrailsApp.groovy:99)
at org.springframework.boot.test.context.SpringBootContextLoader.loadContext(SpringBootContextLoader.java:132)
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:141)
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:90)
... 55 more
Caused by: java.io.IOException: Could not start process: <EOF>
at de.flapdoodle.embed.mongo.AbstractMongoProcess.onAfterProcessStart(AbstractMongoProcess.java:79)
at de.flapdoodle.embed.process.runtime.AbstractProcess.<init>(AbstractProcess.java:116)
at de.flapdoodle.embed.mongo.AbstractMongoProcess.<init>(AbstractMongoProcess.java:53)
at de.flapdoodle.embed.mongo.MongodProcess.<init>(MongodProcess.java:50)
at de.flapdoodle.embed.mongo.MongodExecutable.start(MongodExecutable.java:44)
at de.flapdoodle.embed.mongo.MongodExecutable.start(MongodExecutable.java:34)
at de.flapdoodle.embed.process.runtime.Executable.start(Executable.java:108)
at org.grails.plugin.embedded.mongodb.EmbeddedMongoDBGrailsPlugin.doWithSpring_closure1(EmbeddedMongoDBGrailsPlugin.groovy:60)I'm using it along with a Grails plugin https://github.com/grails/grails-embedded-mongodb/blob/v2.0.1/build.gradle#L43.
michaelmosmann
commented
1 year ago @sagrawal31 this looks like some issue with the other platform on your CI server.. i would guess that there is some library missing as this is no problem locally bc its a different platform (i guess)
as you are using the grails-plugin maybe we must create an issue there..
sagrawal31
commented
1 year ago Thanks, @michaelmosmann. I intentionally commented here instead of raising an issue because I assumed this might be some edge case in this library. I'll raise a comment over there.
michaelmosmann
commented
1 year ago @sagrawal31 i think this pull request needs to be fixed: https://github.com/grails/grails-embedded-mongodb/pull/29
michaelmosmann
commented
1 year ago @sagrawal31 did a new pull request: https://github.com/grails/grails-embedded-mongodb/pull/32
sagrawal31
commented
1 year ago Thanks a ton, @michaelmosmann. Much appreciated! I'll test this moment the PR https://github.com/grails/grails-embedded-mongodb/pull/32 is merged.
Hi All,
Is there any debug logging available with de.flapdoodle.embed.mongo 2.0.1?
My test appears stuck:
This worked fine with 2.0.0 so I suspect something with the new MongoDB version from de.flapdoodle.embed.mongo 2.0.0 to 2.0.1.
I can run my test OK on my local machine but this is running on a work Bamboo build using:
Anything I can tweak in my Maven config for de.flapdoodle.embed.mongo 2.0.1 or a SNAPSHOT build?
Thank you in advance for your help. Gary