-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
“This study run is invalid” #283
Comments
Hi, |
When this happens on a participant's page, the experiment administrator interface appears to be all right, and the pages of other participants who are conducting the experiment at the same time also appear to be all right. Therefore, I think this problem may only occur in the page transmission of a single participant. Thank you for your reply. This server is not owned by me personally, but I will try to inquire about the server's operational status later. By the way, it is indeed a very lightweight server, possibly with only 2 cores and 2G of memory. |
2GB should be okay for a small JATOS instance with not too many users and participants. Do you have access to JATOS administration page, |
I will try this tomorrow. |
I don't know what happen. There seems to be a lot of warnings. But the time stamp seems to be inconsistent with the time in my area. It is difficult to see which warning is related to the failed participant. |
There is a lot going on in your log. Can you please copy-paste it here as text (instead of a screenshot). I can comment easier on text. |
Here. 2023-03-20 07:54:20,376 [WARN] - c.g.a.AuthenticationAction - Authentication failed: remote address 31.56.55.118 tried to access page / |
I cannot find anything in the log that explains the error “This study run is invalid”. There are no hints for a lack of memory or disk space (CPU is usually not a problem with JATOS). But this doesn't mean that memory or disk is not a problem. But there are a couple of strange log messages:
Your study run cannot access an image with the path
Same with these paths.
The batch channel for one study run got opened 10 times in short succession. Usually only once. Strange! Maybe reloads?
That is a strange error. The endpoint exists for a HTTP POST. Do you call this endpoint somehow manually with a different HTTP method? Why? Better use the JATOS API. That's all I can say about the log. Have you got any monitoring of your server? And which version of JATOS do you run? |
I just ran a complete study during this time and some of the problems disappeared and some remained. The problem of opening the batch channel multiple times in a short period of time should always be present. It is not clear what is causing these problems. However, there is nothing unusual about the experimental run page or the administrator interface, except for two extra data records (albeit records without data files). I built this JATOS server four months ago following a tutorial I found on the web, and have not opened the server backend since then. Everything is done on the web page. I don't know if these problems stem from the server side build process. Maybe I should take the time to rebuild the server? I don't know much about this aspect of server building. Thanks for going out of your way to answer this. The exceptions are indeed not related to the "invalid" exception. My JATOS version is 3.7.4. system information is attached below. This is probably a very tricky problem. If you find any solution to this problem, thank you for suggesting it. I will check the log file in time the next time the "invalid" is displayed.
|
Good to know, your server did not crash recently (
You could consider updating your JATOS to 3.8.1. I don't think this will fix your issue but there are some performance improvements in the recent releases that might help especially since you have only 1GB memory on your server. And what's about those file access issues? Did you check the paths in your study? E.g.
But my main concern are these multiple |
Fortunately, these issues will not affect my experimental operation. |
Just now this issue happened again——a participant's screen displayed "invalid". I checked the logs during this period and didn't see any strange exceptions. I have already checked the path issue, it doesn't occur in my local running, but it happens after importing the experimental file to the server. Tonight I will try to update the JATOS server to the latest version. Ideally, it would be best to rebuild the server directly. |
My god! When I updated to the latest version, the structure of the data I collected changed dramatically, which meant that I had to refactor my data analysis code. Is this a normal change after the update? Or did I make a mistake somewhere. |
The line break seems to have disappeared. |
Sorry for the late reply. Can you please elaborate on how the structure of your data changed? What was it before and how does it look now. You say the line breaks disappeared? |
Never mind, I have already solved this problem. Yes, the line breaks did disappear. I wrote a program using JSPsych, and after updating JATOS to the latest version, the line breaks in the data were removed, resulting in all the CSV data being in a single row (there should have been multiple rows, with one row of data for each component). The same thing did not happen in version 3.7.4, so I have now reverted back to that version. I wrote a Python program to deal with the line break issue, but the process was a bit convoluted, especially since my HTML page contained a lot of nested quotes. I didn't do any further testing, so I don't know if this problem is caused by issues with the latest version or compatibility issues between two versions. Perhaps it only occurs in my study. |
Would you care to share how you solve it? Maybe someone else has the same problem and can use your expertise.
I see. I just tried and can confirm. This should not happen. Result data should be allowed to have line-breaks. I created a new bug issue (#285) for this. |
I was sick the other day, so a lot of work has been put on hold, and I apologize for not responding to your message until now. If there were no nested quotes in the html, then this problem would be easily solved by simply inserting line breaks after a specific number of quotes (usually two times the maximum number of columns). However, in Jspsych's data the entire content of the html is usually recorded, for example The pairing status of each quotation mark is first checked one by one. If a character is a paired quotation mark and its next character is not a comma but an unpaired quotation mark, a line-break is inserted between the two. This usually results in broken data. Thanks to Jspsych's data format, which starts with multiple consecutive nulls from the third line, the second step is to merge all lines that do not start with consecutive nulls with the previous line. But I'm not sure that this method works in all cases. Please be sure to perform a data backup before this operation.
|
Thank you for sharing! Maybe it can help others :) |
I am glad to hear this. Is there an expected release time for the new version? |
There is no release date, but I guess within the next 2 weeks. |
This issue seems to be happening with 3.7.6 as well. The data view of the JATOS page seems to be fine, but once exported, the line breaks still disappear. |
Hope the new version will be released soon. |
I'm sorry for the delay. There are some issues related to running JATOS in a cluster with multiple nodes that have to solved before we can release the new version. But hopefully, fingers crossed, next weekend it's going to happen. |
Hi Kristian, Regarding the issue "Internal JATOS error during /publix/[jatos study code]. Check logs to get more information." others have reported in the cogsci forum: We had a similar problem about two weeks ago (a month after the update), when we out of a sudden got the same error message every time any Jatos link was opened in a browser where a Jatos link had been opened at some point before. This problem can be fixed by clearing the browser cache (even though this means all participants need to be instructed to empty their browser cache first). |
Hi! It would have been better to post this kind of question in the CogSci forum since it's more a support kind of question. And secondly it would have been better to post the question in a new thread or issue; just to keep things separated and clean. Sorry for nagging so much ;). But, now, since we are already here ... you have two issues as far as I can see: 1) the connection problems, and 2) the Internal JATOS error due malformed cookies. About 1) The two screenshots show that your participant was not able to reach the JATOS server (lots of connection timeouts, batch channel heartbeat fail, websocket connection fail). So something was broken, either the JATOS server or something between the server and your participant (router, network etc.). Here I can't help much since I do not operate this particular JATOS server nor the other parts of this infrastructure. I'd recommend to contact your admin. About 2) JATOS has a problem dealing with old cookies from older JATOS versions after an update with certain browsers. This is a one-time thing and after one deletes those cookies JATOS works normally. But it is a bug and the next version (v3.8.2) will have a fix for it. Best, |
Hi! |
It doesn't seem to be possible to update directly in the existing server yet, do I need to reinstall the server or will this feature take a few days to implement? My current version is 3.7.6. |
It should be possible to update from 3.7.6 to 3.8.2. Why do you think it is not? |
Yes, looks like some connection issue. And a hint: you can force an update to a certain version by using the 'version' query parameter. Sometimes JATOS doesn't acknowledge the newest version. E.g. for cortex.jatos.org it would be:
|
OK, I'll try it if the internet connection improves. |
Recently I found that even though I no longer have the "This study run is invalid" error, sometimes I still can't find some of the data submitted by participants who have given proof of experiment completion. This problem usually occurs with a 5% probability. After some summarization, I feel that the problem may not be a server issue, but rather that the participants or their devices are doing something unusual during the experiment. A common scenario is that the total runtime of the experiment is sufficient, but it consistently shows not finished yet. Does this stem from the participant closing the end page too quickly? As a result their slow network has not yet uploaded the data or the end-of-experiment signal to the server. In another rare case, the message indicated that the study did not allow refreshing, but the time continued to run for the entire length of time that the experiment should have run, and the participant gave proof of the experiment's completion. Is this due to an "implicit refresh" (there is probably no such thing, I'm just speculating) that does not change the browser display of the study page, but breaks the connection to the server in the background and sends a refresh signal? These are my unprofessional guesses, and I can't say for sure exactly what the problem is caused by. Monitoring the user side is difficult, so solving this problem may be tricky as well. But the problem is certainly annoying. Another issue is that the times in the logs don't seem to be aligned with the time the study was run. I recall that the time of the study run was changed in one of the releases, but the time recorded in the logs was not synchronized with the release change. |
Hi.
Sometimes my participants say that during the experiment, the center of the screen displays “This study run is invalid”.This can happen even when only one participant is experimenting.
The sudden instability can indeed have a significant impact. I don't know if this is due to the stability problem of my server.
Thank anyone for any help and answers.
The text was updated successfully, but these errors were encountered: