-
Notifications
You must be signed in to change notification settings - Fork 21
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
Caching retrieved DTD or XSD schemas #74
Comments
Hi, Tom,
that's a reasonable request, that makes sense, and should be quite doable.
Would you file an isse, on Jira, to have it in the queue, please?
Thanks,
Jochen
…On Fri, Oct 14, 2022 at 11:50 AM Tom Puttemans ***@***.***> wrote:
We are using this plugin to validate a bunch of XML files (1200+ files)
whenever changes are made. We have recently had a networking issue that
caused a 30 second delay in all network requests. That is not really
related to this issue, but it did highlight some unwanted behavior for us
as the execution time suddenly surged from a couple of seconds to more than
3 hours.
Every time the plugin has to resolve a schema from an URL, it retrieves
this schema file from the network. Unless I am completely overlooking
something, it doesn't seem like there is a way to tell the plugin to then
cache those schema files for subsequent use within the same run. Because of
this, network requests are made multiple times for the same files. When the
URL for a file is the same, generally this file will also remain the same.
We've now configured catalog files for these external files and we could
probably also configure a proxy to perform caching for these external
resources. But ideally, an option for such caching would be available
within the plugin to prevent these useless network calls. It shouldn't be
enabled by default, unless it is seen as a changed behavior in a major
release. Caching will really speed up the validations by a lot as well. I
think that honoring the HTTP caching directives isn't really important for
this purpose, but I guess it could make sense to do so. An override for
this would be welcome in that case, though.
—
Reply to this email directly, view it on GitHub
<#74>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIBUGLRRVHIK5YTOHJVMDTWDEUIDANCNFSM6AAAAAARFCL2YA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Philosophy is useless, theology is worse. (Industrial Disease, Dire Straits)
|
Thanks for the reply @jochenw! I'm afraid I'm unable to find/access the Jira. The plugin's documentation points here for issue management. And the few links I found to jira.mojohaus.org all seem to return a network connection error. |
@jochenw - There is no jira nowadays for MojoHaus projects. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are using this plugin to validate a bunch of XML files (1200+ files) whenever changes are made. We have recently had a networking issue that caused a 30 second delay in all network requests. That is not really related to this issue, but it did highlight some unwanted behavior for us as the execution time suddenly surged from a couple of seconds to more than 3 hours.
Every time the plugin has to resolve a schema from an URL, it retrieves this schema file from the network. Unless I am completely overlooking something, it doesn't seem like there is a way to tell the plugin to then cache those schema files for subsequent use within the same run. Because of this, network requests are made multiple times for the same files. When the URL for a file is the same, generally this file will also remain the same.
We've now configured catalog files for these external files and we could probably also configure a proxy to perform caching for these external resources. But ideally, an option for such caching would be available within the plugin to prevent these useless network calls. It shouldn't be enabled by default, unless it is seen as a changed behavior in a major release. Caching will really speed up the validations by a lot as well. I think that honoring the HTTP caching directives isn't really important for this purpose, but I guess it could make sense to do so. An override for this would be welcome in that case, though.
The text was updated successfully, but these errors were encountered: