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."



On Fri, Jan 28, 2022 at 2:12 PM Mike Pham <mpham@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

On 28January, 2022 at 13:17:55, Thad Guidry (thadguidry@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/Upcoming_General_Availability_release

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?



_______________________________________________
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-leave@lists.wikimedia.org

_______________________________________________
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-leave@lists.wikimedia.org