服務商作好的服務,使用tomcat提供的webservice服務,咱們去訪問時過段時間就會報錯。html
這是我把後臺日誌報錯信息,粘貼保存爲一個html後打開的效果。java
以前那個200000是37000,常常報錯,而後同時調整爲了200000,撐的時間長一點,出現異常時就重啓一下。git
服務商說是咱們訪問時沒有斷開鏈接,我檢查了咱們本地代碼,沒什麼問題,百度了xfire的訪問,也沒說要斷開鏈接的。github
這是stackover上一個比較類似的錯誤 https://stackoverflow.com/questions/20482331/whats-causing-these-parseerror-exceptions-when-reading-off-an-aws-sqs-queue-inweb
翻譯:apache
在個人風暴集羣中讀取AWS SQS隊列時,是什麼致使了這些ParseError異常?ubuntu
我正在使用Storm0.8.1從AmazonSQS隊列中讀取傳入消息,並在執行此操做時得到一致的異常:tomcat
2013-12-02 02:21:38 executor [ERROR] java.lang.RuntimeException: com.amazonaws.AmazonClientException: Unable to unmarshall response (ParseError at [row,col]:[1,1] Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.) at REDACTED.spouts.SqsQueueSpout.handleNextTuple(SqsQueueSpout.java:219) at REDACTED.spouts.SqsQueueSpout.nextTuple(SqsQueueSpout.java:88) at backtype.storm.daemon.executor$fn__3976$fn__4017$fn__4018.invoke(executor.clj:447) at backtype.storm.util$async_loop$fn__465.invoke(util.clj:377) at clojure.lang.AFn.run(AFn.java:24) at java.lang.Thread.run(Thread.java:701) Caused by: com.amazonaws.AmazonClientException: Unable to unmarshall response (ParseError at [row,col]:[1,1] Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.) at com.amazonaws.http.AmazonHttpClient.handleResponse(AmazonHttpClient.java:524) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:298) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:167) at com.amazonaws.services.sqs.AmazonSQSClient.invoke(AmazonSQSClient.java:812) at com.amazonaws.services.sqs.AmazonSQSClient.receiveMessage(AmazonSQSClient.java:575) at REDACTED.spouts.SqsQueueSpout.handleNextTuple(SqsQueueSpout.java:191) ... 5 more Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.setInputSource(XMLStreamReaderImpl.java:219) at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.<init>(XMLStreamReaderImpl.java:189) at com.sun.xml.internal.stream.XMLInputFactoryImpl.getXMLStreamReaderImpl(XMLInputFactoryImpl.java:277) at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:129) at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLEventReader(XMLInputFactoryImpl.java:78) at com.amazonaws.http.StaxResponseHandler.handle(StaxResponseHandler.java:85) at com.amazonaws.http.StaxResponseHandler.handle(StaxResponseHandler.java:41) at com.amazonaws.http.AmazonHttpClient.handleResponse(AmazonHttpClient.java:503) ... 10 more
我已經調試了隊列中的數據,一切看起來都很好。我不明白API的XML響應爲何會致使這些問題。有什麼想法嗎?oracle
回答:async
多年來一直在回答我本身的問題。
目前在Oracle和OpenJDK的Java中有一個XML擴展限制處理錯誤,致使共享計數器在解析多個XML文檔時會碰到默認上限。
https://blogs.oracle.com/joew/entry/jdk_7u45_aws_issue_123
https://bugs.openjdk.java.net/browse/jdk-8028111
https://github.com/aws/aws-sdk-java/issues/123
雖然我認爲咱們的版本(6B27-1.12.6-1ubuntu0.12.04.4)沒有受到影響,可是運行OpenJDK bug報告中給出的示例代碼確實驗證了咱們對該bug的敏感性。
爲了解決這個問題,我須要將jdk.xml.EntityExpansionLimit=0傳遞給Storm Workers。經過在集羣的storm.yaml中添加如下內容,我能夠緩解這個問題。
supervisor.childopts:「-djdk.xml.entityExpansionLimit=0」
worker.childopts:「-djdk.xml.entityExpansionLimit=0」
我應該注意到,從技術上講,這會使您面臨拒絕服務攻擊,可是因爲咱們的XML文檔只來自於SQS,因此我不擔憂有人僞造惡意的XML來殺死咱們的工做人員。
可能還有更多。我在使用Java6時也遇到一樣的錯誤。個人機器上沒有安裝Java7。
不要介意。發現這也會影響Java五、六、7和8的特定版本。詳情請參見:bugs.openjdk.java.net/browse/jdk-8028111–brianc mar 19'14,15:00
你們好,我只需在程序中添加「system.setproperty」(「jdk.xml.entityExpansionLimit」,「0」)一行就解決了這個問題。奇怪的是,當使用從命令行傳遞給程序的參數做爲參數時,問題仍然存在。
根據Java文檔,將「JDK.XML.EntEngestExpCurimeLim限度」屬性設置爲「0」並無限制。應使用負值禁用實體擴展。docs.oracle.com/javase/tutorial/jaxp/limits/limits.html
---------------end------------------------
後續,等待與機構商溝通,有解決辦法了再更新