-
Notifications
You must be signed in to change notification settings - Fork 384
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
CLDR-14913 Add Download XML button to Survey Tool #4010
Conversation
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
Note: To obtain those screenshots, I removed common/annotations/ff.xml locally. It is essentially empty and if present it leads to verification failure: "present in baseline but not in vxml". However, if absent, the result is “TestFileIds Error: (TestCLDRFile.java:814) Error: Missing simple parent (ff) for ff_Adlm in common/annotations; likely=ff_Adlm” |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
-Front end: new GenerateVxml.vue, cldrGenerateVxml.mjs -Back end: new GenerateVxml.java, VxmlQueue.java, VxmlGenerator.java -Run the task in its own thread, with multiple http requests fetching status until done -Partly imitate implementation of Priority Items Summary: GenerateVxml.java corresponds to Summary.java; VxmlGenerator.java corresponds to VettingViewer.java; VxmlQueue.java corresponds to VettingViewerQueue.java -Revise OutputFileManager.java as needed and also to fix some (not all) compiler warnings -Disable Announce requests while VXML generation is in progress (only on front end; only affects the browser of the Admin user, not other users if running on remote server) -Fix bug in XPathTable.loadXPaths, DB connection without commit, change getDBConnection to getAConnection for auto-commit (pre-existing bug was especially problematic throwing exception when generating VXML) -Improve debugging feature in DBUtils.java slightly and add comment about remaining imperfection -Use auto-commit in STFactory.setupDB and make the related boolean dbIsSetup private -Remove dead code -Comments
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
Note: the green on red is almost impossible to read. Black on red? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far.
* Ordinarily announcements are enabled. They may be temporarily disabled during | ||
* critical operations such as VXML generation, or for debugging. | ||
*/ | ||
let announcementsEnabled = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does it make a difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thrown exceptions due to uncommitted non-auto-commit db connections were preventing VXML generation from running to completion. While debugging that, the Announce requests were running in parallel with the VXML requests, making the problem harder to track down. In the past there have also been concurrency bugs when generation was implemented as an auto-scheduled background task, and it's not clear whether those were ever solved or just avoided by not auto-scheduling. Even when all is going well, I like to keep an eye on the various things that are happening during VXML generation. Temporarily disabling announcements reduces complexity and server load and makes for one less thing to worry about.
cldrAjax | ||
.doFetch(VXML_URL, init) | ||
.then(cldrAjax.handleFetchErrors) | ||
.then((r) => r.json()) | ||
.then(setVxmlData) | ||
.catch((e) => { | ||
cldrNotify.exception(e, "generating VXML"); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could consider using cldrClient - provides error checking of input parameters. at least for future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea for future enhancement. I'll study it. I think there may still be problem with cldrClient when running locally with nginx, confusion between ports 8888 and 9080. It can be bypassed by skipping nginx and going directly to 9080, but I'd like to get it working right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it works via nginx in production. And anyway, I think the baseline url issue may have been fixed when I fixed a similar issue with Chrome.
Or, maybe it's not fixed in main, it's waiting in the "CLA PR" which is awaiting review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"CLA PR"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"CLA PR"?
#3653 - i'll rebase and merge it.
set.remove(CLDRLocale.getInstance("en")); | ||
set.remove(CLDRLocale.getInstance(LocaleNames.ROOT)); | ||
// Remove "mul", "mul_ZZ", etc. | ||
set.removeIf(loc -> loc.getBaseName().startsWith(LocaleNames.MUL)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use SpecialLocales.java instead - in fact, if SpecialLocales.getType() returns non-null then skip. (sandbox (mul). algorithmic (sr_Latn) and other readonly.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try that. This is really a tangential issue -- see ticket https://unicode-org.atlassian.net/browse/CLDR-14953 -- but it was super distracting always getting verification warnings/errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried that and got different results. These locales get removed, so VXML isn't generated: ha_NE, sr_Latn, sr_Latn_BA, sr_Latn_ME, sr_Latn_XK, yo_BJ. They are all "algorithmic". Their files are present and not "empty" in baseline. If they don't get VXML generated, we'll get "Verification failure, file(s) present in baseline but not in vxml".
Would it be OK to merge this PR as-is, and then follow up with improvements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
such files should be copied from baseline and not (re)generated.
Yes. As I mentioned in a comment with one of the screenshots, that text is carried over from the old interface and I don't see any benefit to it:
I'd like to do that in a follow-up PR since this PR is already far-reaching and accomplishes the essential goals of modernizing the client-server interface and using a separate thread on the server rather than taking ten minutes for the server to respond to the original request. |
-Front end: new GenerateVxml.vue, cldrGenerateVxml.mjs
-Back end: new GenerateVxml.java, VxmlQueue.java, VxmlGenerator.java
-Run the task in its own thread, with multiple http requests fetching status until done
-Partly imitate implementation of Priority Items Summary: GenerateVxml.java corresponds to Summary.java; VxmlGenerator.java corresponds to VettingViewer.java; VxmlQueue.java corresponds to VettingViewerQueue.java
-Revise OutputFileManager.java as needed and also to fix some (not all) compiler warnings
-Disable Announce requests while VXML generation is in progress (only on front end; only affects the browser of the Admin user, not other users if running on remote server)
-Fix bug in XPathTable.loadXPaths, DB connection without commit, change getDBConnection to getAConnection for auto-commit (pre-existing bug was especially problematic throwing exception when generating VXML)
-Improve debugging feature in DBUtils.java slightly and add comment about remaining imperfection
-Use auto-commit in STFactory.setupDB and make the related boolean dbIsSetup private
-Remove dead code
-Comments
CLDR-14913
ALLOW_MANY_COMMITS=true