Yes it does, I'll add my comment to the discussion then:
"As the Search team has looked into this already and stated they see no
alternative to knowing which users are issuing problematic queries that can
bring down the service to all, then I think to ensure minimum availability
to all users that authentication should be required. Without
authentication, the team says that service degradation can still occur but
we would not have a clear signal who might be causing a problem for all to
help correct behavior or that users' needs. This is no different than
other API service providers with public endpoints requiring an API user key
or token for identification in case it's needed to contact that user."
Thad
On Fri, Jan 28, 2022 at 2:12 PM Mike Pham <mpham(a)wikimedia.org> wrote:
Hi Thad,
Thanks for the question. I’ll address the question to the best of my
ability, but a more technically savvy person from my team can correct me if
I get the details wrong.
Is it still the case that the team is unable to kill a problematic query?
Problematic queries can lock up Blazegraph, causing it to be unresponsive.
In this case, the only solution is to restart Blazegraph, as we are unable
to ask it to kill the problematic query. Unfortunately, restarting
Blazegraph does not guarantee that the user agent can simply resend that
same query again, causing the cycle to continue. This is one of the
contexts in which we talk about authentication providing our team with more
tools to handle problematic queries bringing down the query service.
I noted the discussion also about “authentication” with WCQS Beta 2 coming
Feb. 2.
Small correction (might have been a typo), but WCQS beta 2 is scheduled to
be live in Tues Feb 1.
Hope that helps answer your question!
Best,
Mike
—
*Mike Pham* (he/him)
Sr Product Manager, Search
Wikimedia Foundation <https://wikimediafoundation.org/>
On 28January, 2022 at 13:17:55, Thad Guidry (thadguidry(a)gmail.com) wrote:
Thanks Mike,
I noted the discussion also about "authentication" with WCQS Beta 2 coming
Feb. 2.
Reading through some of the talk over the past few months (and catching up
from holidays)...
https://commons.wikimedia.org/wiki/Commons_talk:SPARQL_query_service/Upcomi…
Once a problematic query is executed, it can lock up Blazegraph and cause
it to become unresponsive – because we are unable to kill the query, we are
forced to restart Blazegraph manually each time, causing user-wide
disruptions, and taking a lot of emergency time and energy for the WMF team
to resolve (at the expense of other improvements, features, projects).
Is it still the case that the team is unable to kill a problematic query?
Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/
_______________________________________________
Wikidata mailing list -- wikidata(a)lists.wikimedia.org
To unsubscribe send an email to wikidata-leave(a)lists.wikimedia.org
_______________________________________________
Wikidata mailing list -- wikidata(a)lists.wikimedia.org
To unsubscribe send an email to wikidata-leave(a)lists.wikimedia.org