You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Trejkaz (Jira)" <ji...@apache.org> on 2021/10/08 03:00:07 UTC
[jira] [Comment Edited] (LUCENE-5572) JapaneseTokenizer is
sensitive to interrupts
[ https://issues.apache.org/jira/browse/LUCENE-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425927#comment-17425927 ]
Trejkaz edited comment on LUCENE-5572 at 10/8/21, 3:00 AM:
-----------------------------------------------------------
A GUI application running outside our context is interrupting the thread in order to cancel a long-running operation. This is still, to my knowledge at least, the only remaining way to do this in Java. There's a general expectation in Java that code will behave correctly when an interrupt occurs.
If I'm the developer of that end-user application, I'm not sure how I'm expected to detect whether someone somewhere in the process is about to load a class.
We're the developers of the _library_, and even we don't know how to detect that.
The only context in which someone knows a class is being loaded is Lucene itself, which is why the ticket is filed here.
What "design issue" are you talking about? If you point to something specific then I can investigate it, but just hand-waving "design issue" doesn't give me any useful information to go on.
As for design, a general principle of software design is to shield the caller from things they shouldn't need to know about.
So the GUI application is shielding the user from needing to know that they're using our library.
Our library is shielding the GUI application from needing to know that they're using Lucene.
What is Lucene doing to shield its users from this quirky interrupt behaviour of Java?
Who has the design issue here?
was (Author: trejkaz):
A GUI application running outside our context is interrupting the thread in order to cancel a long-running operation. This is still, to my knowledge at least, the only remaining way to do this in Java. There's a general expectation in Java that code will behave correctly when an interrupt occurs.
If I'm the developer of that end-user application, I'm not sure how I'm expected to detect whether someone somewhere in the process is about to load a class.
We're the developers of the _library_, and even we don't know how to detect that.
The only context in which someone knows a class is being loaded is Lucene itself, which is why the ticket is filed here.
What "design issue" are you talking about? If you point to something specific then I can investigate it, but just hand-waving "design issue" doesn't give me any useful information to go on.
As for design, a general principle of design is to shield the caller from things they shouldn't need to know about.
So the GUI application is shielding the user from needing to know that they're using our library.
Our library is shielding the GUI application from needing to know that they're using Lucene.
What is Lucene doing to shield its users from this quirky interrupt behaviour of Java?
Who has the design issue here?
> JapaneseTokenizer is sensitive to interrupts
> --------------------------------------------
>
> Key: LUCENE-5572
> URL: https://issues.apache.org/jira/browse/LUCENE-5572
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Affects Versions: 3.6.2
> Reporter: Anthony Rasmussen
> Priority: Minor
>
> The constructor for JapaneseTokenizer gets the following singleton instances: TokenInfoDictionary, UnknownDictionary, and ConnectionCosts. I am finding that the associated getInstanceMethods are particularly sensitive to IOExceptions.
> Perhaps, in the static initializers of these 3 singletons, there could be some sort of retry effort before throwing a RunTimeException?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org