2017-12-18 11 views
0

teiid 가상 프로 시저를 사용하여 나머지 API를 만들고 데이터를 노출합니다. 캐시 힌트를 사용하여 결과 세트 캐싱을 활성화했습니다. 동일한 API 요청을 두 번 보내면 두 번째 시도에서 데이터가없고 teiid 콘솔에서 벨로우즈 예외를 기록합니다. 그러나 캐싱을 사용할 수 없거나 캐시가 무효화 될 때까지 대기 한 후 두 번째 요청을 보내는 경우 (ttl 시간 이후) 요청이 적절하게 실행되고 관련 응답을받습니다. 그리고 내가 한 또 다른 중요한 관찰은 응답 크기가 일부 크기보다 작을 때 (예 : LIMIT 절을 사용하여 응답 크기를 10 개의 레코드로 제한) 캐싱을 사용하도록 설정하면 요청이 제대로 제공된다는 것입니다. 이것은 특정 크기 (내 경우 15) 이후에 레코드 크기를 늘리는 경우에만 발생합니다."응답이 커밋 됨, 예외를 처리 할 수 ​​없습니다"오류 동일한 Rest API 요청을 두 번 보낼 때

이 문제점 및 수정 사항이나 해결 방법의 이유를 알고 있으므로이 문제점 없이도 결과 세트 캐싱을 계속 사용할 수 있습니까?

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

'주 서버 그룹'아래에 하나의 서버 만 사용하고 있습니다. 처음에는 기본적으로 '기타 서버 그룹'아래에 두 개의 다른 서버가 있었으며 구성에서 제거했습니다. 이 문제에 대한 가능한 모든 링크가 있습니다. 그리고이 서버를 'ha'프로필 아래에 구성했습니다. 'full-ha'를 사용하면 얻을 수있는 추가 혜택을 알 수 있습니까 – Sanjewa

답변

0

나는 이것을위한 해결책을 발견 할 수 있었다. @ramesh가 언급 한대로 jdbc cliet를 시도했습니다. 그러나 문제는 지속됩니다. 이 문제는 REST API에서 검색하는 XML 및 JSON 형식 응답에 대해 모두 유지됩니다. 응답 크기가 teiid의 기본 제한 인 4000자를 초과하는 경우에만 발생합니다. 관리 콘솔을 사용하여 시스템 속성에서이 한도를 늘리고 teiid 클러스터를 다시 시작합니다.

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

이렇게하면이 빈 캐시 응답 문제가 해결되었습니다.