Skip to content
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.

Sign up for GitHub

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

Jump to bottom

HTTPServerLoadTest can get stuck #13

Closed
danielnaber opened this issue Oct 1, 2013 · 8 comments
Closed

HTTPServerLoadTest can get stuck #13

danielnaber opened this issue Oct 1, 2013 · 8 comments
Assignees
@slotties

Comments

@danielnaber
Copy link
Member

It happened to me once that the test got stuck with 200% CPU load. The stacktrace was this (quoting only the part that matters):

"pool-3-thread-6" prio=10 tid=0x00007f790c2d4800 nid=0x6a93 runnable [0x00007f7950c87000]
   java.lang.Thread.State: RUNNABLE
    at java.util.HashMap.getEntry(HashMap.java:446)
    at java.util.HashMap.containsKey(HashMap.java:434)
    at org.languagetool.rules.patterns.UnifierConfiguration.setEquivalence(UnifierConfiguration.java:60)
    at org.languagetool.rules.patterns.XMLRuleHandler.finalizeTokens(XMLRuleHandler.java:569)
    at org.languagetool.rules.patterns.PatternRuleHandler.endElement(PatternRuleHandler.java:275)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endNamespaceScope(XMLDTDValidator.java:2054)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2005)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:879)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1742)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2900)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:568)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:302)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
    at org.languagetool.rules.patterns.PatternRuleLoader.getRules(PatternRuleLoader.java:71)
    at org.languagetool.JLanguageTool.loadPatternRules(JLanguageTool.java:311)
    at org.languagetool.JLanguageTool.activateDefaultPatternRules(JLanguageTool.java:345)
    at org.languagetool.server.LanguageToolHttpHandler.getLanguageToolInstance(LanguageToolHttpHandler.java:296)
    at org.languagetool.server.LanguageToolHttpHandler.checkText(LanguageToolHttpHandler.java:230)
    at org.languagetool.server.LanguageToolHttpHandler.handle(LanguageToolHttpHandler.java:108)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
    at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80)
    at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:677)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
    at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:649)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)
"pool-3-thread-5" prio=10 tid=0x00007f790c2d2800 nid=0x6a92 runnable [0x00007f7950d88000]
   java.lang.Thread.State: RUNNABLE
    at java.util.HashMap.getEntry(HashMap.java:446)
    at java.util.HashMap.containsKey(HashMap.java:434)
    at org.languagetool.rules.patterns.UnifierConfiguration.setEquivalence(UnifierConfiguration.java:60)
    at org.languagetool.rules.patterns.XMLRuleHandler.finalizeTokens(XMLRuleHandler.java:569)
    at org.languagetool.rules.patterns.PatternRuleHandler.endElement(PatternRuleHandler.java:275)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endNamespaceScope(XMLDTDValidator.java:2054)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2005)
    at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:879)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1742)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2900)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:568)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:302)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
    at org.languagetool.rules.patterns.PatternRuleLoader.getRules(PatternRuleLoader.java:71)
    at org.languagetool.JLanguageTool.loadPatternRules(JLanguageTool.java:311)
    at org.languagetool.JLanguageTool.activateDefaultPatternRules(JLanguageTool.java:345)
    at org.languagetool.server.LanguageToolHttpHandler.getLanguageToolInstance(LanguageToolHttpHandler.java:296)
    at org.languagetool.server.LanguageToolHttpHandler.checkText(LanguageToolHttpHandler.java:230)
    at org.languagetool.server.LanguageToolHttpHandler.handle(LanguageToolHttpHandler.java:108)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
    at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80)
    at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:677)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
    at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:649)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)
@danielnaber
Copy link
Member Author

I guess this could be fixed by using this code in UnifierConfiguration?

equivalenceTypes = Collections.synchronizedMap(new HashMap<EquivalenceTypeLocator, Element>());
equivalenceFeatures = Collections.synchronizedMap(new HashMap<String, List<String>>());

@milekpl
Copy link
Member

milekpl commented Oct 1, 2013

Hm, seems sensible to me. Did you try it?

@danielnaber
Copy link
Member Author

I cannot reproduce the bug, so there's not much I can try (except running the tests and that works).

@slotties
Copy link
Contributor

slotties commented Oct 1, 2013

Urg, that sure is a problem. The UnifierConfiguration was supposed to be
immutable once the language is completely initialized while the Unifier
(created by a UnifierConfiguration) is stateful. A synchronized map (or
java.util.ConcurrentHashMap) is a temporary workaround, but I'd prefer them
to be cached somehow to improve the speed of creating a JLanguageTool.

I think we should use a ConcurrentHashMap for now, because at least
Unifier.startNextToken uses the keySet() of
UnifierConfiguration.equivalenceFeatures and a Collections.synchronizedMap
is supposed to be synchronized externally in such cases:
--- snip ---
It is imperative that the user manually synchronize on the returned map
when iterating over any of its collection views:
[...]
--- snip ---

btw, I guess it's a good time to share my thoughts on how I wanted to
improve rule loading anyway. The idea is to move loaded rules to either an
own structure or to the language. In both cases the rules are then provided
to the JLanguageTool rather than being loaded by the JLanguageTool itself.
This change allows the (API-)user to cache/hold the rules and set up a
JLanguageTool very fast (in case he uses rules). But I don't know when I
actually start working on it (maybe in the next days, because it's a long
weekend), so I'm fine with implementing a workaround for now, as mentioned
above.

On Tue, Oct 1, 2013 at 8:55 PM, Daniel Naber notifications@github.comwrote:

I guess this could be fixed by using this code in UnifierConfiguration?

equivalenceTypes = Collections.synchronizedMap(new HashMap<EquivalenceTypeLocator, Element>());
equivalenceFeatures = Collections.synchronizedMap(new HashMap<String, List>());

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-25477608
.

slotties added a commit that referenced this issue Oct 1, 2013
@slotties
implemented workaround for concurrent usage of the equivalenceTypes a…
74c061b 
…nd equivalenceFeatures (Issue #13)
@slotties
Copy link
Contributor

slotties commented Oct 1, 2013

I just committed a fix that seems to work. Well, I could reproduce the problem a few times with the FrenchConcurrencyTest. The HashMaps has been replaced by ConcurrentHashMaps and the ArrayList stored as value in the equivalenceFeatures has been replaced by a CopyOnWriteArrayList. The later change is 'just in case'.

I was not able to reproduce the bug in the HTTPServerLoadTest, so I'm keen to see if you can still reproduce the bug.

@danielnaber
Copy link
Member Author

I could never reproduce it, it only happened once (but I didn't try running the test for hours...). Could you please document your fix in CHANGES.txt?

slotties added a commit that referenced this issue Oct 2, 2013
@slotties
added hint for issue #13
088e45c
@slotties
Copy link
Contributor

slotties commented Oct 2, 2013

Done.

@ghost ghost assigned slotties Oct 2, 2013
@slotties
Copy link
Contributor

slotties commented Oct 3, 2013

I'll close this issue as it should've been fixed now. Issue #14 might change something on this fix, hopefully the removal of the concurrent collections that were implemented as workaround.

@slotties slotties closed this as completed Oct 3, 2013
@danielnaber danielnaber mentioned this issue Oct 9, 2013
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slotties slotties

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@danielnaber @slotties @milekpl