SLiM server died before a connection could be established #726
Comments
|
Hello Thurmann, could you share what kind of test you are running and the command string generated by FitNesse? Please share the command string for your test with and and without debug option and for a standard FitNesse acceptance test. Run all with your latest FitNesse version and run it directly from the Wiki. Also share standard out and standard error captured during each run which you can see on the same page. I assume there are some spaces or quotes in the slim command line and the processing of the same has changed some time back. Due to this your client doesn't starts at all but dies immediately. |
|
Hi, Thanks for your reply. The error message I get is the following:
This error message seems a bit strange since all the modules in my project are configured to use jdk 1.7. Update: It seems like the project was configured to use 1.8 while the modules used 1.7. However, after I changed the project setting to 1.7 I still get the same error message, only with the path slightly changed("jdk1.7.0_67" instead of "jdk1.8.0_25") The command line starts with the following:
Note that there is a space in between "Program" and "Files". Could this be the problem? I receive this error message for all the tests that I have in my suite. It doesn't matter what the tests contain, be it script tables, query tables etc., the result is always the same. When running the standard acceptance tests in FitNesse I do not get this error. The test string for the acceptance test only contains the postfix "?test" |
|
Seems like the classpath has not been put into quotation marks. Dipl.-Inform. Markus Gärtner http://www.shino.de/blog
|
|
Why should this not be a problem for version 20140901 of FitNesse? I have no problems with the classpath for anything else, so why should it be a problem with FitNesse? And how can the remote debug option still work? |
|
I tried again now after changing the classpath to include quotations. Still I get the same error message. Command line for ordinary test:
Command line for remote debug test, which still works:
|
|
I think you ought to out each individual path in quotes, iirc. Dipl.-Inform. Markus Gärtner http://www.shino.de/blog
|
|
I haven't manipulated the command line in any way, that change was merely the consequence of me changing the classpath to include quotes. Additionally, I can't see why this should be a problem now when it's not a problem for FitNesse version 20140901 and remote debug. |
|
Hi Thurmann Looking at the cp of your test you see that it starts without a quote and with jar: C:\Users\E212786.m2\repository\org\fitnesse\fitnesse\20150424\fitnesse-20150424.jar; And after this the remaining cp is in one single set of quotes. The same jar is repeated in the remaining cp again. So it is not required at the beginning. Looking at your debug test you see it does not starts with this jar and all cp elements are in one set of quotes. This is how it should be. I assume you have to remove this jar for your test and it will work. Did you modified the testrunner variable for your test? Otherwise test and debug test should have the same cp. |
|
The jar file that you mention is added by FitNesse, it's not something I have added manually if that's what you're thinking. If you look in ClientBuilder.java you can see:
Here the %p is replaced with the classpath.
So that's why the quote is not added to the fitnesse jar, but to the rest of the command line. Which I think is a bug. Regarding why debug still works, you can look at the ClientBuilder.java again and see that it contains:
This string does not seem to contain the fitnesse jar, which would explain why debug works. |
|
Good analysis.
I would also say that using different classpath variables for test and debug is a bug. And that in case of test the quotes are not added correctly to the full path.
But both doesn't explains why it worked with an older version.
Can you share the command generated for test with version 20140901.
|
|
I looked into the history of the ClassPath.java and saw that there was a commit on 01.10.2014 which added the quotes to the toString() method. Additionally this class did not exist before 06.09.2014 so it could not have been used at all in the 20140901 release. I think this would explain why the 20140901 version works, while all the later ones does not. The command line from version 20140901:
As you can see this command does not contain any quotes even though the classpath contains spaces(see installation folder for IntelliJ, the last argument). And this works. |
|
Just wanted to note that I've seen similar issues with the classpath for another project when trying to upgrade from FitNesse 20140901 to a newer version. (The same project also ran into issue in an older FitNesse release, but have not seen it in 20140901. Might have been the same as #498, since that was also partly caused by paths containing spaces.) One thing I find interesting with your classpath is that you seem to be running your project from IntelliJ IDEA. I've seen similar issues when running FitNesse from IntelliJ, but have not been able to reproduce it when starting from Eclipse. Presumably the two IDEs organize/construct the classpath in slightly different ways, so that might explain it. I don't remember if there was any obvious differences in the classpath output though. Could you check with your project if you run into the same problems when starting from Eclipse? If so, we might want to look into how these two constructs the classpath and why FitNesse seems to have trouble with it. |
|
Hi @Thurmann, I think you found the root cause. Could you try to add below on your test page, just to see if the test then works with the latest FitNesse version: The quotes around the classpath are not required forJava but are required for the fitsharp runner as mentioned by @sergebug in PR #532. The cleanest solution I see is to add another replacement option %P (uppercase) to ClientBuilder. This is replaced with the concatenation of fitnesseJar and classPath combined with proper quotes.
|
|
@six42 I added the command pattern to the test and then the test works on version 20150424. @hansjoachim I can't see how this could only be a problem for IntelliJ? The default command pattern strings consists of an incorrect sequence imo. and I'm a little bit confused as to how this specific issue has seemingly not been reported before. I will try to run it from Eclipse and see whether that changes anything |
|
Glad to hear that it works. I think the error was not noticed before as most people avoid folders with spaces as this creates always trouble. As you are already deep in the code would you like to create a pull request to fix this? |
|
I really don't think I have enough knowledge about the FitNesse project to propose any changes. The solution may seem trivial enough but there should be a reason for why the fitnesse jar was added to the command pattern in the first place? |
@Thurmann To be fair, I don't know. However, I've seen similar issues with FitNesse and classpaths. There, everything would run without issues if launched from Eclipse, but if you launched from IntelliJ instead, the tests wouldn't run. Through investigation/debugging, the only difference found was how the classpath looked between the two. In this case, the problem went away with 20140901, but has since resurfaced. Unfortunately, I haven't had time to dig properly into it, so I can't say for certain, but I suspect it might be the same issue as this one. |
|
Hi gals and guys, I'm getting the same error message for quite a different reason, because any failure is hard coded to display it, in SlimCommandRunningClient at line 93 you have: if you look deeper into the code the actual error message is logged at line 82 of command runner, but it is not displayed to the output. I'm going to try to fix that and make a pull request... |
|
Actual output of the error message from the command line added here: |
|
#772 has been merged. I suppose that resolves the issue (for now). |
|
Actually I do see here that FitNesse knows that the Java process failed to startup, so would there be different exception hangling code run if the server dies later, so we can differentiate between a startup failure and the server dying? This is in reference to the other note I put on the pull request @amolenaar Let me know if we should do anything else or we can leave it as so. |
|
As I mentioned above, I've seen similar issues. After some debugging and rereading this, I understand more of the comments above. The core of the issue is outlined in #726 (comment) and #726 (comment). While FitNesse wraps the classpath in quotation marks if it contains spaces, the COMMAND_PATTERN will prepend fitnesse.jar to this String which triggers the problem. Unfortunately I am still able to reproduce this with 20150814, so it is not fixed. @Thurmann could you confirm? A suggested fix is mentioned above, by introducing a new COMMAND_PATTERN which will combine the fitnesse jar and the rest of the classpath with proper quotes. Alternatively, both in this case and in the project where I see the problem, it looks like fitnesse.jar is already part of the classpath, so perhaps it doesn't need to be explicitly added by the COMMAND_PATTERN? (I'm no classpath expert though, so I don't know if there might be cases where it isn't included.) Other comments and questions: I also verified that @six42's workaround ( |
So the executed command will look like: |
Correct. See the first part of #726 (comment) for a real life example. Also note that it works when run as debug (since debug run use a different pattern, DEFAULT_JAVA_DEBUG_COMMAND, which doesn't add the fitnesse jar). |
Problem Description
I think I have uncovered a possible defect in Fitnesse, more specifically after version 20140901.
I can't seem to find any other person that have experienced a similar problem, so I figured that I should post it here.
When starting a test in Fitnesse I get the following error:
My OS is Windows 7 and I'm running Fitnesse in a Java project which uses jdk1.7.
Problem Diagnosis
I have performed some diagnosis to try to figure out what could be the reason for this error.
I am cooperating with another person who uses a Mac instead of Windows, and he does not experience this error.
When ONLY changing the Fitnesse version in maven pom I have uncovered the following:
When debugging the error I have found the following:
Another peculiar thing that I found was that when using the remote debug option in Fitnesse(?responder=test&remote_debug=true), the test works and no errors occur(This works on version 20150114, 20150424 and 20150226).
So, what could be the cause for this error? According to my diagnosis this problem started to occur after version 20140901.
The text was updated successfully, but these errors were encountered: