2017-12-18 46 views
0

teiid Virtual Procedureを使用して、Rest APIを作成し、データを公開しています。キャッシュヒントを使用して結果セットキャッシングを有効にしました。同じAPIリクエストを2回送信すると、2回目の試行でデータが取得されず、teiidコンソールはベローの例外を記録します。しかし、キャッシングが無効になっている場合や、キャッシュが無効になるまで(ttl時間後)にリクエストが正常に実行され、関連する応答が得られるまで待ってから2番目のリクエストを送信すると、また、レスポンスサイズがあるサイズよりも小さくなるように制限されている場合(たとえば、LIMIT句を使用してレスポンスサイズを10レコードに制限するなど)、キャッシュが有効な状態でリクエストが適切に処理されるという重要な点があります。これは、特定のサイズ(私の場合は15)の後にレコードサイズを増やした場合にのみ発生します。「レスポンスがコミットされ、例外を処理できません」エラー同じRest APIリクエストを2回送信するとエラーが発生する

この問題の原因と解決策や回避策を知っているので、この問題を起こさずに結果セットのキャッシュを引き続き使用できますか?

05:04:52,909 ERROR [io.undertow.request] (default task-20) UT005023: Exception handling request to /TestView_1/report/get_data: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception 
    at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:167) 
    at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471) 
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:415) 
    at org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:240) 
    at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:225) 
    at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:62) 
    at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) 
    at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) 
    at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) 
    at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) 
    at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) 
    at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) 
    at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) 
    at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) 
    at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) 
    at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) 
    at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) 
    at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) 
    at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) 
    at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) 
    at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) 
    at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) 
    at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
    at java.lang.Thread.run(Thread.java:748) 
Caused by: java.io.IOException: already removed 
    at org.teiid.common.buffer.FileStore.checkRemoved(FileStore.java:162) 
    at org.teiid.common.buffer.FileStore.read(FileStore.java:156) 
    at org.teiid.common.buffer.FileStore$1.nextBuffer(FileStore.java:223) 
    at org.teiid.common.buffer.ExtensibleBufferedInputStream.ensureBytes(ExtensibleBufferedInputStream.java:42) 
    at org.teiid.common.buffer.ExtensibleBufferedInputStream.read(ExtensibleBufferedInputStream.java:54) 
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) 
    at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) 
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) 
    at java.io.InputStreamReader.read(InputStreamReader.java:184) 
    at java.io.Reader.read(Reader.java:100) 
    at org.teiid.core.util.ReaderInputStream.read(ReaderInputStream.java:94) 
    at org.teiid.core.util.ObjectConverterUtil.write(ObjectConverterUtil.java:106) 
    at org.teiid.core.util.ObjectConverterUtil.write(ObjectConverterUtil.java:143) 
    at org.teiid.core.util.ObjectConverterUtil.write(ObjectConverterUtil.java:139) 
    at org.teiid.jboss.rest.TeiidRSProvider$1.write(TeiidRSProvider.java:72) 
    at org.jboss.resteasy.plugins.providers.StreamingOutputProvider.writeTo(StreamingOutputProvider.java:32) 
    at org.jboss.resteasy.plugins.providers.StreamingOutputProvider.writeTo(StreamingOutputProvider.java:17) 
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131) 
    at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60) 
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120) 
    at org.jboss.resteasy.security.doseta.DigitalSigningInterceptor.aroundWriteTo(DigitalSigningInterceptor.java:145) 
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124) 
    at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100) 
    at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124) 
    at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98) 
    at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466) 
    ... 33 more 
+0

結果セットのサイズが小さい場合、結果はディスクに書き込まれる特定のサイズの後で、メモリに保持されます。エラーは、保存されたものがTTLの前にどのように削除されたかをキャッシュしていることを示しているようです。 REST APIなしでクエリを実行すると、同じエラーが存在するかどうかを確認できますか? –

+0

odataなどのプロトコルを使用して仮想プロシージャ・モデルにリクエストを発行しようとしましたか? – Sanjewa

+0

私は 'メインサーバーグループ'の下に1台のサーバーしか使用していません。当初、デフォルトでは、「その他のサーバーグループ」の下に2つの他のサーバーがあり、それらを構成から削除しました。それはこの問題の可能性のあるリンクです。そして、私はこのサーバーを 'ha'プロフィールの下に設定しました。 「full-ha」を使用した場合に得られる追加の利点を知ることができます – Sanjewa

答えて

0

私はこの解決策を見つけることができました。 @rameshが述べたようにJdbc clietを試しました。しかし問題は残っている。 この問題は、REST APIから取得するXMLとJSON形式のレスポンスの両方で維持されます。 これは、応答サイズがteiidのデフォルトの制限である4000文字を超える場合にのみ発生します。私はこの制限を管理コンソールを使ってシステムのプロパティから増やし、teiidクラスタを再起動しました。

property      value boot-time 
org.teiid.maxStringLength 200000 true 

この空のキャッシュレスポンスの問題を解決しました。

関連する問題