this is my first question on stackoverflow, so, im not very clear the rule of it..
my server got a error on jetty. this error often appear when a lot of request to the server.
the error is:
09-24 01:45:40.091 [qtp1379435698-982] WARN org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:265) - HttpConnection#6ddcef89{FILLING}
java.lang.IllegalStateException: s=DISPATCHED i=true a=null
at org.eclipse.jetty.server.HttpChannelState.handling(HttpChannelState.java:231)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:282)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
after a lot of this error appear, the jetty has restarted.
the jetty version is 9.2.7.v20150116.
I am very much looking forward to your answer
Related
I tried to upgrade WSO2 EI to 6.5.0 from 6.4.0 and tried to Start server. The following error occurs and server is not up. How can I find reference to org_apache_tomcat_websocket ?Everything works fine when I revert back to 6.4.0
[2021-01-21 06:59:26,908] [] ERROR - ContainerBase A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/]]
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1243)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:819)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1707)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1697)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:162)
... 6 more
Caused by: java.lang.IllegalArgumentException: More than one fragment with the name [org_apache_tomcat_websocket] was found. This is not legal with relative ordering. See section 8.2.2 2c of the Servlet specification for details. Consider using absolute ordering.
at org.apache.catalina.deploy.WebXml.orderWebFragments(WebXml.java:2338)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1268)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:881)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:388)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5590)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
... 6 more
[2021-01-21 06:59:26,939] [] ERROR - ContainerBase A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost]]
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1243)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:300)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.wso2.carbon.tomcat.ext.service.ExtendedStandardService.startInternal(ExtendedStandardService.java:49)
Thanks for the help.
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 have the same problem as laalto - Axis2 error while running web service.
The following exception occurs when I call the webservice, although the service seems to run properly:
06-16#11:46:05 DEBUG DataRetrievalUtil - File does not exist in the Service Repository! File=META-INF/ServiceData.xml [http-bio-8080-exec-9]
06-16#11:46:05 DEBUG AxisDataLocatorImpl - Check loading failure for file, META-INF/ServiceData.xml.Message = Failed to load from file, META-INF/ServiceData.xml [http-bio-8080-exec-9]
06-16#11:46:05 DEBUG AxisDataLocatorImpl - Check loading failure for file, META-INF/ServiceData.xml [http-bio-8080-exec-9]
org.apache.axis2.dataretrieval.DataRetrievalException: Failed to load from file, META-INF/ServiceData.xml
at org.apache.axis2.dataretrieval.DataRetrievalUtil.buildOM(DataRetrievalUtil.java:64)
at org.apache.axis2.dataretrieval.AxisDataLocatorImpl.loadServiceData(AxisDataLocatorImpl.java:104)
at org.apache.axis2.description.AxisService.getDefaultDataLocator(AxisService.java:2949)
at org.apache.axis2.description.AxisService.getDataLocator(AxisService.java:2933)
at org.apache.axis2.description.AxisService.getData(AxisService.java:2850)
at org.apache.axis2.description.AxisService.getWSDL(AxisService.java:1545)
at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1355)
at org.apache.axis2.transport.http.ListingAgent.processListService(ListingAgent.java:198)
at org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:258)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
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:744)
Caused by: javax.xml.stream.XMLStreamException: File does not exist in the Service Repository! File=META-INF/ServiceData.xml
at org.apache.axis2.dataretrieval.DataRetrievalUtil.getInputStream(DataRetrievalUtil.java:103)
at org.apache.axis2.dataretrieval.DataRetrievalUtil.buildOM(DataRetrievalUtil.java:60)
... 26 more
My webservice project is about two years old and its structure has never changed since than. The structure is:
Webservices.war|-----axis2-web
|-----META-INF|
|------MANIFEST.MF
|-----WEB-INF |
|------web.xml
|------sources.....
And there has never been a file called "ServiceData.xml".
I use Tomcat 7.0_39 with Axis2 1.5.6. The webservice component was implemented with Java 1.7.0_21.
Is it possible that this error previously appeared without have been logged yet? -I changed the logging behaviour of the webservices with the last deployment.
I found some hints to rename the "services.xml" to "ServiceData.xml", but is this really a proper solution?
Thanks in advance!
This solution worked for me:
The exception seems to have no impact since there is the services.xml in folder
webapps/WebServices/WEB-INF/services/WebService/META-INF
Therefore one can ignore this exception. Nevertheless an exception always indicates an error and therefore it should be solved.
I found a solution, which is not satifying but prevents the exception from occurring:
Copy the services.xml in the folder above and rename it to ServiceData.xml. The exception will never occur! To simply place an empty file named ServiceData.xml does not work! The ServiceData.xml must contain the same information as the file services.xml!
This is unfortunately a practical, but not a good solution, because it fixes not the cause of this exception but the impact.
If there is a better solution please contribute here!
I'm trying to get an OAuth application up, but I fail because the API servers won't talk to me. Unfortunatly the used clj-apache-http won't tell me what was the problem, I only get this warning:
WARNUNG: Authentication error: Unable to respond to any of these challenges: {oauth=WWW-Authenticate: OAuth realm="http%3A%2F%2FSERVERNAME"}
Exception in thread "Thread-1" java.lang.RuntimeException: java.lang.Exception: JSON error (unexpected character): I (example.clj:1)
at clojure.lang.AFn.run(AFn.java:28)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: JSON error (unexpected character): I (example.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:5440)
at clojure.lang.Compiler.load(Compiler.java:5857)
at clojure.lang.RT.loadResourceScript(RT.java:340)
at clojure.lang.RT.loadResourceScript(RT.java:331)
at clojure.lang.RT.load(RT.java:409)
at clojure.lang.RT.load(RT.java:381)
at clojure.core$load$fn__4511.invoke(core.clj:4905)
at clojure.core$load.doInvoke(core.clj:4904)
at clojure.lang.RestFn.invoke(RestFn.java:409)
at clojure.core$load_one.invoke(core.clj:4729)
Ok, now that isn't helping me. There is a strange character I as the first one in the response - that's clearly no JSON.
I want to get the log level of apaches HTTPClient up to DEBUG now, but I don't know how to set system properties via leiningen. Any tips?
This is a way to get all requests by clj-apache-http through a local debugging proxy:
(require ['com.twinql.clojure.http :as 'http])
(:content
(http/get (java.net.URI. "http://yourhost.com")
:parameters (http/map->params {
:default-proxy (http/http-host
:host "127.0.0.1"
:port 8765)}) :as :string))
Alternatively, you could add this to your log4j.properties:
log4j.logger.httpclient.wire.header=DEBUG
log4j.logger.httpclient.wire.content=DEBUG
log4j.logger.org.apache.commons.httpclient=DEBUG
log4j.logger.org.apache.http=DEBUG
log4j.logger.org.apache.http.wire=DEBUG
Which will dump all communication to your log file. This is useful don't want to change the code that makes the request.
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.