I am using teiid Virtual Procedure to create a Rest API and expose my data. I have enabled result set caching using Cache Hints. When I send the same API request twice I get no data in the second attempt and teiid console logs the bellow exception. However when the caching is disabled or if I send the second request after waiting till the cache get invalidated (after ttl time) requests are executed properly and I get the relevant response. And another important observation that i made is that when the response size is limited to be less than some size (eg. using LIMIT clause to limit response size to 10 records), the requests are served properly with caching enabled. This happens only when I increase the records size after a particular size (in my case 15).
Can I know the reason behind this and any fixes or workarounds so I can continue to use result set caching without having this issue.
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
I was able to find the solution for this. I tried Jdbc cliet as #ramesh mentioned. But the issue persist.
This issue persist for both XML and JSON format responses we retrieve from REST API.
This only happens when the response size is larger than 4000 characters which is the default limit for teiid. I increased this limit from the System Properties using management console and re-start the teiid cluster.
property value boot-time
org.teiid.maxStringLength 200000 true
This solved this Empty cache response issue.
Related
I am trying to replace the default LevelDB in OpenDaylight with Apache Ignite which i am unable to do after making changes to the akka.conf file and deploying the akka-persistence-ignite jar that i found here. https://github.com/Romeh/akka-persistance-ignite
I am facing an issue in the following line of the source code (AbstractDataStoreClientActor class) where it throws a Runtime Exception.
private static final Function1<ActorRef, ?> GET_CLIENT_FACTORY = ExplicitAsk.toScala(GetClientRequest::new);
#SuppressWarnings("checkstyle:IllegalCatch")
public static DataStoreClient getDistributedDataStoreClient(#Nonnull final ActorRef actor,
final long timeout, final TimeUnit unit) {
return (DataStoreClient) Await.result(ExplicitAsk.ask(actor, GET_CLIENT_FACTORY,
Timeout.apply(timeout, unit)), Duration.Inf());
which gives the following error
akka.pattern.AskTimeoutException: Ask timed out on [Actor[akka://opendaylight-cluster-data/user/$a#-809157907]] after [30000 ms]. Sender[null] sent message of type "org.opendaylight.controller.cluster.databroker.actors.dds.GetClientRequest".
My question is how can i know the behavior of the actor to which the above message is sent? Is there any way to check if the actor has been created properly? What could be the reason for which the Ask method is going to timeout?
EDIT:::: error stack trace from karaf.log
2018-07-12T11:27:01,755 | ERROR | opendaylight-cluster-data-akka.actor.default-dispatcher-18 | DistributedDataStoreClientActor | 90 - com.typesafe.akka.slf4j - 2.5.11 | Persistence failure when replaying events for persistenceId [member-1-frontend-datastore-config]. Last known sequence number [0]
java.lang.NullPointerException: null
at akka.japi.Util$.option(JavaAPI.scala:271) ~[84:com.typesafe.akka.actor:2.5.11]
at akka.persistence.snapshot.japi.SnapshotStore.$anonfun$loadAsync$1(SnapshotStore.scala:20) ~[87:com.typesafe.akka.persistence:2.5.11]
at scala.util.Success.$anonfun$map$1(Try.scala:251) ~[323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at scala.util.Success.map(Try.scala:209) ~[323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at scala.concurrent.Future.$anonfun$map$1(Future.scala:288) ~[323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:29) ~[323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:29) ~[323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60) ~[323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55) ~[84:com.typesafe.akka.actor:2.5.11]
at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:91) ~[84:com.typesafe.akka.actor:2.5.11]
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12) [323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:81) [323:org.scala-lang.scala-library:2.12.5.v20180316-130912-VFINAL-30a1428]
at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:91) [84:com.typesafe.akka.actor:2.5.11]
at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40) [84:com.typesafe.akka.actor:2.5.11]
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) [?:?]
The issue is not with DistributedDatastoreClientActor - it is a side-effect of an issue with the persistence backend - see my previous comment. Notice that the error stack trace contains an NPE emanating from akka.persistence.snapshot.japi.SnapshotStore which indicates the backing SnapshotStore unexpectedly returned null from loadAsync. This points to the ignite plugin.
I am using SWF for one of my application where I used ExponentialRetry to poll continuously for an activity result. However sometime the activity caused START_TO_CLOSE timeout. This does not happen for all my workflows and happens 1 in 30 there by making it difficult to debug/reproduce. From the deciders logs i can see below. Could someone explain what the issue might be?
com.amazon.metrics.swf.AwsSwfMetricsRequestHandler: An error was thrown in previous decision in the thread <SWF Decider AWSFuncTaskList_110.0 7>, task-token <AAAAKgAAAAIAAAAAAAAAAgwtVps42342343434343A3hvItwKY0Vav/Kpexk2cat5fsWkiN1SxhfeoRwVgl+F2/EZQrhBP4RoA41LmLLC77WLU26uSMXaVnl+Cz64x+RZP0sBzofJWdAOdiwHAzsePFNQETXfyl+HibRiYxxO4Xyxn8ndVQ50f97W3IKkwrO7mySJSXbpe6Yaw/AiPmi4f6VoqQo/+nhRSEbzQpKNQeZAaCcAB/6oxEKOgYbW75AF9JsPbZEOdYE7Kq2JVjyghP2id9xAGKgj3ww3d1UBoRFxlulSUsNJmlpgR2+HPyWDHZKF7ECw==>, workflow-execution <RiskAnalysis-313434142331#22NB47i321UtA7w9dPnUTmmtKMeIP1DWrepdAJb0WdGqc=>, domain <Prod>, workflow-type <RiskAnalysisWF#1.7>
at com.amazon.metrics.swf.DecisionsMetricsExtractor.internalHandlePollForDecisionTask(DecisionsMetricsExtractor.java:183)
at com.amazon.metrics.swf.DecisionsMetricsExtractor.handlePollForDecisionTask(DecisionsMetricsExtractor.java:168)
at com.amazon.metrics.swf.AwsSwfMetricsRequestHandler.handlePollForDecisionTask(AwsSwfMetricsRequestHandler.java:508)
at com.amazon.metrics.swf.AwsSwfMetricsRequestHandler.extractMetrics(AwsSwfMetricsRequestHandler.java:362)
at com.amazon.metrics.sdk.AwsSdkMetricsRequestHandler.handleCall(AwsSdkMetricsRequestHandler.java:218)
at com.amazon.metrics.sdk.AwsSdkMetricsRequestHandler.afterResponse(AwsSdkMetricsRequestHandler.java:196)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.afterResponse(AmazonHttpClient.java:975)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:746)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:717)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:699)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:667)
at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:649)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:513)
at com.amazonaws.services.simpleworkflow.AmazonSimpleWorkflowClient.doInvoke(AmazonSimpleWorkflowClient.java:3390)
at com.amazonaws.services.simpleworkflow.AmazonSimpleWorkflowClient.invoke(AmazonSimpleWorkflowClient.java:3366)
at com.amazonaws.services.simpleworkflow.AmazonSimpleWorkflowClient.executePollForDecisionTask(AmazonSimpleWorkflowClient.java:2112)
at com.amazonaws.services.simpleworkflow.AmazonSimpleWorkflowClient.pollForDecisionTask(AmazonSimpleWorkflowClient.java:2088)
at com.amazonaws.services.simpleworkflow.flow.worker.DecisionTaskPoller.poll(DecisionTaskPoller.java:191)
at com.amazonaws.services.simpleworkflow.flow.worker.DecisionTaskPoller.access$000(DecisionTaskPoller.java:39)
at com.amazonaws.services.simpleworkflow.flow.worker.DecisionTaskPoller$DecisionTaskIterator.next(DecisionTaskPoller.java:71)
at com.amazonaws.services.simpleworkflow.flow.worker.DecisionTaskPoller$DecisionTaskIterator.next(DecisionTaskPoller.java:45)
at com.amazonaws.services.simpleworkflow.flow.worker.HistoryHelper$EventsIterator.<init>(HistoryHelper.java:269)
at com.amazonaws.services.simpleworkflow.flow.worker.HistoryHelper$SingleDecisionEventsIterator.<init>(HistoryHelper.java:74)
at com.amazonaws.services.simpleworkflow.flow.worker.HistoryHelper.<init>(HistoryHelper.java:318)
at com.amazonaws.services.simpleworkflow.flow.worker.AsyncDecisionTaskHandler.handleDecisionTask(AsyncDecisionTaskHandler.java:73)
at com.amazonaws.services.simpleworkflow.flow.worker.DecisionTaskPoller.pollAndProcessSingleTask(DecisionTaskPoller.java:223)
at com.amazonaws.services.simpleworkflow.flow.worker.GenericWorker$PollServiceTask.run(GenericWorker.java:85)
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)
All activities have a startToCloseTimeout when they are created (by the Decider). If not explicitly specified, they use the default from the versioned ActivityType that is defined in SWF for that activity. You are hitting the timeout because your retries are allowing you to go past that configured timeout. If you think you need more time, then when the activity is created, you will need to specify the startToCloseTimeout as a larger value in the scheduleActivityTaskDecision.
I am building a Rest client with cpprest-sdk to communicate with a web service. The problem is that every once in a while, after sending multiple successful requests (around 50), I get the exception:
WinHttpSendRequest: 2148074273 insufficient cache in function
Or sometimes:
ERROR_WINHTTP_SECURE_FAILURE (12175)
I tried to look for cache options in cpprest-sdk but did not find anything. Since the exceptions happens inside cpprest-sdk when I call .wait() on my task I am not sure if I can use the WINHTTP_STATUS_CALLBACK to check for more details on this error. How can I investigate deeper to find the cause of this error?
Here is my Rest request:
void MyRestClient::PostKeys(const std::string & sKek, const std::string & sKid, const std::string & sCustomerAuthenticator) {
uri_builder oBuilder(U("/keys?customerAuthenticator=") + to_string_t(sCustomerAuthenticator));
oBuilder.append_query(KEK, to_string_t(sKek));
json::value oBody;
oBody[KID] = json::value::string(to_string_t(sKid));
web::http::http_request oRequest;
oRequest.set_method(methods::POST);
oRequest.set_request_uri(oBuilder.to_uri());
oRequest.set_body(oBody);
m_oCurrentTask = oClient.request(oRequest).then([this](http_response oResponse) {
OnPostResponse(oResponse);
});
}
According to https://msdn.microsoft.com/en-us/library/windows/desktop/aa383928(v=vs.85).aspx (4th bullet), Post requests should not be cached so I don't understand why I am getting the first exception. I also tried to disable Https caching as the 6th bullet in the link suggest, but that did not change anything.
Did anyone experienced something similar or have any insight as to what may be happening? Or is this a normal behavior and should I just retry my request when these exceptions happens?
Does your Web Service use TLS with Diffie-Hellman key exchange? If yes, you are probably seeing a bug in SChannel, which is the SSL implementation of Windows, see here for a confirmation. Unfortunately, the only available fix is an update of the Windows version on which your client is running to a recent build of Windows 10.
I'm using glassfish 2.1.1. I've watched a mysterious http/webservice-call handling. It seams an http request is handled by two different threads.
After http basic authentication the first thread is faster. Persisting some data end, but writing response fails in glassfish internal.
The second thread fails, because it tries to persist identical data and there are (unique) constrain failures. The response (the failure) of second thread was delivered to client.
I don't won't discuss the behavior with the unique constrain failure. I've improve the webservice, so it can handle this better, because it could be happen anytime, that the client send the ws call a second time.
But I think, glassfish 2.1.1 has an bug handling http request. Is there any known issue? Have I done an mistake?
[#|2010-03-22T10:40:54.150+0000|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs) ...|#]
...
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Received WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|Received WebService call to enqueue() from client 59|#]
...
[#|2010-03-22T11:18:44.267+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Successfully finished WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.329+0000|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|invocation error on ejb endpoint MyWebService at /MyWebserviceService/MyWebservice : com.sun.xml.stream.XMLStreamException2
javax.xml.ws.WebServiceException: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:111)
at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:281)
at com.sun.xml.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:320)
at com.sun.xml.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:93)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:454)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:231)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:157)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.executeServlet(CometEngine.java:616)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.handle(CometEngine.java:362)
at com.sun.enterprise.web.connector.grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:84)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:189)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:164)
at com.sun.enterprise.web.connector.grizzly.async.AsyncProcessorTask.doTask(AsyncProcessorTask.java:92)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:264)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:416)
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:109)
... 36 more
Caused by: ClientAbortException: java.nio.channels.ClosedChannelException
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:385)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:351)
at org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:176)
at com.sun.xml.stream.writers.UTF8OutputStreamWriter.flush(UTF8OutputStreamWriter.java:153)
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:414)
... 37 more
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:126)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:91)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:66)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:172)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushChannel(AsynchronousOutputBuffer.java:81)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:205)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushBuffer(AsynchronousOutputBuffer.java:114)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:183)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flush(AsynchronousOutputBuffer.java:104)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.action(DefaultProcessorTask.java:1100)
at org.apache.coyote.Response.action(Response.java:237)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:381)
... 41 more
|#]
[#|2010-03-22T11:18:44.376+0000|WARNING|sun-appserver2.1|oracle.toplink.essentials.session.file:/mygf-211/domains/mydomain/applications/j2ee-apps/myear/myjar-myPu|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|
Local Exception Stack:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.1 (Build b31g-fcs (10/19/2009))): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Eine Zeile mit doppeltem Schlüssel kann in das 'dbo.MY_TABLE'-Objekt mit dem eindeutigen 'MY_INDEX'-Index nicht eingefügt werden.
I did a quick search at https://glassfish.dev.java.net/issues/query.cgi and did not see a report that looked like a duplicate of the situation that you are encountering here... though I may have missed it.
You should probably report this issue to the GlassFish developers, via their issue tracker: https://glassfish.dev.java.net/servlets/ProjectIssues.
You may have misread the log or done something wrong in your code, but this is really hard to tell given the limited amount of info that you have given in this question... But, SO doesn't really work as an issue analysis/resolution system. The GF issue tracker is a better choice for that.
Lately, we've been seeing exceptions like this in our .NET (.asmx) webservices:
System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (868, -3932). ---> System.Xml.XmlException: '.', hexadecimal value 0x00, is an invalid character. Line 868, position -3932.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
at System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
at System.Xml.XmlTextReaderImpl.ThrowInvalidChar(Int32 pos, Char invChar)
at System.Xml.XmlTextReaderImpl.ParseNumericCharRefInline(Int32 startPos, Boolean expand, BufferBuilder internalSubsetBuilder, Int32& charCount, EntityType& entityType)
at System.Xml.XmlTextReaderImpl.ParseText(Int32& startPos, Int32& endPos, Int32& outOrChars)
at System.Xml.XmlTextReaderImpl.ParseText()
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlTextReader.Read()
at System.Web.Services.Protocols.SoapServerProtocol.SoapEnvelopeReader.Read()
at System.Xml.XmlReader.ReadElementString()
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read14_SendErrlog()
at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer12.Deserialize(XmlSerializationReader reader)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
--- End of inner exception stack trace ---
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle)
at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
--- End of inner exception stack trace ---
at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
How can I debug this exception? This exception is getting reported to us from a SOAP filter which looks for exceptions in message.Stage = SoapMessageStage.AfterSerialize.
Is there any way to get at the original soap request? How do I get an invalid character at line 868, column -3932? How can there a negative column 3932?
This is one of the irritating things about the Microsoft web services approach -- if the request cannot be deserialized into the objects in your web method signature then the service consumer gets a cryptic message. And to top it off, the request never makes it into your web service because it cannot be deserialzied so you can't handle the error gracefully.
What I would do to help with these types of issues is to create a new SoapExtension that simply lets you output the raw XML to a destination that is convenient for you (file or Trace to be read by DebugView or whatever else you like). The code would go in the BeforeDeserialize stage. You could enable the SoapExtension via web.config in the event you wanted to investigate one of these issues. The downside of using the web.config to add the SoapExtension is that it will be active for the entire web application. You could add some additional custom configuration that would allow your service to only log information for a specific endpoint or a specific web method if you wanted.
Usually, just by seeing the incoming XML you can see what the problem is. If not, then you could try to manually run the captured XML through small program that invokes the XML serializer and see if you can find out what is going on. Another useful tool is Web Service Studio 2 which is a test harness which lets you enter data and invoke your service (and also submit any XML you want).
In terms of your specific issue, here is my take/guess. It looks like ASCII character null is getting encoded and sent to your service which is invalid according to the XML Spec. The simple answer is not to send that character. But who is sending that character? Is it a .NET client? Do you have control over the client? If you need to work around someone else's bug, then you may have to replace the offending character(s) with another character (perhaps empty string).
You should be able to get the original message by using another SoapExtension. In fact, the same extension could probably be modified to make a copy of the input, and to discard it if there is no exception. The original input would then be available to you if an exception occurred.
You could also use an external tool like Fiddler to watch what's being sent to you.
FYI: SoapException.Message is intentionally left vague to prevent exposing too much information which could potentially be used to exploit the system.
For your particular case I'd take John's advice and install Fiddler to monitor the actual HTTP traffic and view the message on the wire.
The portion of your exception that jumps out at me is the "hexadecimal value 0x00, is an invalid character" but as you mentioned the line number it points to is bunk--so it's nothing concrete.
What kind of parameters do you pass to the service? Are you doing any kind of custom encoding with a SOAP extension? Any additional SOAP headers being added?