When we make a Web Services API call, sometimes we are not getting response back. Our thread is just waiting for a response and does not get an error back. Time outs are specified in the web service request using com.sun.xml.ws.request.timeout parameter. But, time outs are not working in this scenario.
Environment details:
Application server: Weblogic
Operating System: Linux
Web services API: Metro
Does anyone have any idea about this issue?
Stack trace:
"DefaultQuartzScheduler_Worker-88" RUNNABLE native
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
weblogic.utils.io.ChunkedInputStream.read(ChunkedInputStream.java:159)
java.io.InputStream.read(InputStream.java:89)
com.certicom.tls.record.ReadHandler.readFragment(Unknown Source)
com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
com.certicom.tls.record.ReadHandler.read(Unknown Source)
com.certicom.io.InputSSLIOStreamWrapper.read(Unknown Source)
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
java.io.BufferedInputStream.read(BufferedInputStream.java:235)
weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:220)
weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:143)
weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:463)
weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:357)
weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:945)
com.sun.xml.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:209)
com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:160)
com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:93)
com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:116)
com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:112)
com.sun.xml.xwss.XWSSClientPipe.process(XWSSClientPipe.java:154)
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
com.sun.xml.ws.client.Stub.process(Stub.java:222)
com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:135)
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
$Proxy87.getMapping(Unknown Source)
The stack trace shows the socket is opened between the client and the web service. There is some reading happening i.e. data transfer but it might be taking very long.
Is the client on Weblogic or the web service hosted on Weblogic or both?
Can you check netstat -an | grep
Does it show the sockets in ESTABLISHED state? or some other state like TIME_WAIT or CLOSE_WAIT ?
How long have you configured your stuck-thread-timeout?
The default is 600 seconds, so does this operation take longer than 10 minutes?
Try adding "com.sun.xml.ws.connect.timeout".
Both properties are also available in constant form:
com.sun.xml.ws.client.BindingProviderProperties.REQUEST_TIMEOUT
com.sun.xml.ws.client.BindingProviderProperties.CONNECT_TIMEOUT
Make sure you don't use internal imports, it won't work on WebLogic.
Related
I am trying to use the throttling functionality of WSO2. I have published on API with few subscription tiers made available for subscribers and added an advanced throttling policy as 5 requests per minute.
After that, I am subscribing to the API through an Application. The application level limit is set to 10 requests per minute and the subscriber is using a subscription tier of 5 requests per minute while subscribing to that API.
Now, I generate a test token with the production key and use it to invoke the API. But, here issue is that I am able to access the API more number of times than the limit I have set. It sometimes gives message for quota exceeded after 13 or 14 requests in a minute and sometimes it doesn't even give a message.
At the same time I am getting an exception at the backend on wso2 server console as below.
Exception in thread "pool-39-thread-111" java.lang.NumberFormatException: For in
put string: "0:0:0:0:0:0:0:1"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Long.parseLong(Unknown Source)
at java.lang.Long.parseLong(Unknown Source)
at org.wso2.carbon.apimgt.impl.utils.APIUtil.ipToLong(APIUtil.java:5826)
at org.wso2.carbon.apimgt.gateway.throttling.publisher.DataProcessAndPub
lishingAgent.run(DataProcessAndPublishingAgent.java:149)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
[2016-09-23 12:11:29,355] INFO - AndesRecoveryTask Running DB sync task.
need some help here...
Unfortunately, currently this supports only IPv4. I created a bug report. It will be fixed in next version.
https://wso2.org/jira/browse/APIMANAGER-5397
So, for now either you'll have to move to IPv4 or fix the error in this method yourself and patch the server.
Test cluster of two brokers, WKA membership scheme, PostgreSQL message store, working fine for a couple of days, then throwing following errors:
TID: [] [] [2016-07-19 12:09:24,738] ERROR {org.wso2.andes.server.protocol.MultiVersionProtocolEngine} - Error establishing session {org.wso2.andes.server.protocol.MultiVersionProtocolEngine}
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:218)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45)
at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Thread.java:745)
Startup of Message Broker looks fine, no errors, JDBC connection to PostgreSQL DB is ok, Registry mount looks ok. Then after that error appears in wso2carbon.log several times/minute.
Anyone any ideas? As far as I know nothing's changed and I don't know what it's trying to connect to.
This usually happens when client's whom connected to MB tries to create connections per message. jms is heavy connection and not recommended to create connections per each message. Therefore, please go through client implementation and verify connections are not created per message.
If by any chance you are using wso2 esb to publish/subscribe queues/topics to mb there is a property "transport.jms.CacheLevel" connection caching in esb axis2.xml.Read the documentation and use appropriate caching level for your usecase.
There was bug in connection caching property to be ignored in esb 4.8.1 which is currently fixed in 4.9.0 as well.
These are the possible cases I can think of with the given information. If you need more info please provide a detailed usecase.
I created a web app which use mysql. I used spring for the persistence.
Every thing worked on my local tomcat server.
I upload it into cloudfoundary, I follow the instuction and I create a mysql service and I use it
as a service for my web-app.
I try to run the app and I got the following exceptions:
HTTP Status 500 -
--------------------------------------------------------------------------------
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:812)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:868)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:876)
com.tutorialspoint.StudentJDBCTemplate.create(StudentJDBCTemplate.java:19)
com.tutorialspoint.Hello.doGet(Hello.java:58)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
root cause
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1116)
com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:344)
com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2332)
com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:792)
com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:381)
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:305)
java.sql.DriverManager.getConnection(DriverManager.java:582)
java.sql.DriverManager.getConnection(DriverManager.java:154)
org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173)
org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164)
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149)
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnection(AbstractDriverBasedDataSource.java:119)
org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:812)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:868)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:876)
com.tutorialspoint.StudentJDBCTemplate.create(StudentJDBCTemplate.java:19)
com.tutorialspoint.Hello.doGet(Hello.java:58)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
root cause
java.net.ConnectException: Connection refused
java.net.PlainSocketImpl.socketConnect(Native Method)
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
java.net.Socket.connect(Socket.java:529)
java.net.Socket.connect(Socket.java:478)
java.net.Socket.<init>(Socket.java:375)
java.net.Socket.<init>(Socket.java:218)
com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:257)
com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:294)
com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2332)
com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:792)
com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:381)
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:305)
java.sql.DriverManager.getConnection(DriverManager.java:582)
java.sql.DriverManager.getConnection(DriverManager.java:154)
org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173)
org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164)
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149)
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnection(AbstractDriverBasedDataSource.java:119)
org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:573)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:812)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:868)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:876)
com.tutorialspoint.StudentJDBCTemplate.create(StudentJDBCTemplate.java:19)
com.tutorialspoint.Hello.doGet(Hello.java:58)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
note The full stack trace of the root cause is available in the Apache Tomcat/6.0.35 logs.
--------------------------------------------------------------------------------
Apache Tomcat/6.0.35
If the problem is still there: there are 2 ways to configure a connection to CF services.
1) Taking the advantage of "auto-reconfigure". For any Java app, if it is using Spring framework, the doc here specifically described the details: http://docs.cloudfoundry.com/frameworks/java/spring/spring.html
2) For Java apps, other than Spring apps, the details of connection to the CF provisioned services like hostname or password needs to be taken care explicitly. These can be retrieved by an environment variable named "VCAP_SERVICES". Simply this code snippet can achieve that:
System.getenv("VCAP_SERVICES")
After that set the properties to the connection configuration.
We are developing an application for an academic course of software architecture and we must use Java EE to implement that.
Essentially we have to implement a distributed Hearts game(you know the Windows game? I think so).
We want to use SOAP to make the client able to communicate with the server (glassfish in our case) but to avoid polling we need to implement the web service endpoint as a #WebServiceProvider.
Such kind of endopoit can implement the asyncProvider interface that allow us to decoplue soap request and soap response. But here we have 2 big problems:
The first one is that: glassfish (without any additional settings) can use a set of only 5 threads in the http-thread-pool. After the first five request we have the endopoint servlet "blocked". Is that the right mode to work of asyncProvider? After the invoke termination we were expecting that the servlet thread was released to process another one incoming request but, apparently, it does not work in this way. It's not a real "async" managment of the request. Are we wrong?
The second one: We are pretty sure that the problem we are introducing is strictly correlated with the first one. Making ten request with a thread pool size of 5 we have this scenario: The first five requests are well processed and, after a timeout of 20 seconds, they are correctly sent to the client. From the sixth to the last we have some mistake: in the server side everything is ok, but in the client-side and only sometimes we have an excpetion like this:
java.util.concurrent.ExecutionException: javax.xml.ws.WebServiceException: java.net.SocketException: Unexpected end of file from server
at com.sun.xml.ws.util.CompletedFuture.get(CompletedFuture.java:72)
at client.Client$1.handleResponse(Client.java:79)
at com.sun.xml.ws.client.AsyncResponseImpl.set(AsyncResponseImpl.java:125)
at com.sun.xml.ws.client.sei.AsyncMethodHandler$SEIAsyncInvoker$1.onCompletion(AsyncMethodHandler.java:202)
at com.sun.xml.ws.client.Stub$1.onCompletion(Stub.java:397)
at com.sun.xml.ws.api.pipe.Fiber.completionCheck(Fiber.java:503)
at com.sun.xml.ws.api.pipe.Fiber.run(Fiber.java:423)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.xml.ws.WebServiceException: java.net.SocketException: Unexpected end of file from server
at com.sun.xml.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:214)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:162)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:93)
at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.run(Fiber.java:422)
... 3 more
Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at com.sun.xml.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:210)
... 10 more
We want to highlight that the content of the soap response is validated and well-formed after checking it without any exception at the server side.
If we send a number of request lower than the http-thread-pool size we have no problem.
Any suggestion for us?
I'm currently running Mirth 2.0.1.5164 with JDK 1.6 update 10 on Windows XP SP3. I kept getting this error every time I want to deploy a Web Service Listener/Sender channel:
[2011-04-11 09:31:11,947] ERROR (com.mirth.connect.server.controllers.MuleEngineController:207): Error registering channel.
org.mule.providers.FatalConnectException: ReconnectStrategy "org.mule.providers.SingleAttemptConnectionStrategy" failed to reconnect receiver on endpoint "ws://127.0.0.1:8041"
at org.mule.providers.SingleAttemptConnectionStrategy.doConnect(SingleAttemptConnectionStrategy.java:34)
at org.mule.providers.AbstractConnectionStrategy.connect(AbstractConnectionStrategy.java:67)
at org.mule.providers.AbstractMessageReceiver.start(AbstractMessageReceiver.java:391)
at org.mule.providers.AbstractConnector.registerListener(AbstractConnector.java:508)
at org.mule.impl.model.AbstractModel.registerListeners(AbstractModel.java:231)
at org.mule.impl.model.AbstractModel.registerComponent(AbstractModel.java:187)
at com.mirth.connect.server.controllers.MuleEngineController.registerChannel(MuleEngineController.java:327)
at com.mirth.connect.server.controllers.MuleEngineController.deployChannels(MuleEngineController.java:201)
at com.mirth.connect.server.servlets.EngineServlet.doPost(EngineServlet.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:677)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)Caused by: org.mule.providers.FatalConnectException: ReconnectStrategy "org.mule.providers.SingleAttemptConnectionStrategy" failed to reconnect receiver on endpoint "ws://127.0.0.1:8041"
at org.mule.providers.SingleAttemptConnectionStrategy.doConnect(SingleAttemptConnectionStrategy.java:34)
at org.mule.providers.AbstractConnectionStrategy.connect(AbstractConnectionStrategy.java:67)
at org.mule.providers.AbstractMessageReceiver.connect(AbstractMessageReceiver.java:348)
at org.mule.providers.SingleAttemptConnectionStrategy.doConnect(SingleAttemptConnectionStrategy.java:32)
... 22 moreCaused by: org.mule.providers.ConnectException: Initialisation Failure: runtime modeler error: Wrapper class com.mirth.connect.connectors.ws.jaxws.AcceptMessage is not found. Have you run APT to generate them?
at org.mule.providers.AbstractMessageReceiver.connect(AbstractMessageReceiver.java:362)
at org.mule.providers.SingleAttemptConnectionStrategy.doConnect(SingleAttemptConnectionStrategy.java:32)
... 25 moreCaused by: com.sun.xml.internal.ws.model.RuntimeModelerException: runtime modeler error: Wrapper class com.mirth.connect.connectors.ws.jaxws.AcceptMessage is not found. Have you run APT to generate them?
at com.sun.xml.internal.ws.model.RuntimeModeler.getClass(Unknown Source)
at com.sun.xml.internal.ws.model.RuntimeModeler.processDocWrappedMethod(Unknown Source)
at com.sun.xml.internal.ws.model.RuntimeModeler.processMethod(Unknown Source)
at com.sun.xml.internal.ws.model.RuntimeModeler.processClass(Unknown Source)
at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(Unknown Source)
at com.sun.xml.internal.ws.server.EndpointFactory.createSEIModel(Unknown Source)
at com.sun.xml.internal.ws.server.EndpointFactory.createEndpoint(Unknown Source)
at com.sun.xml.internal.ws.api.server.WSEndpoint.create(Unknown Source)
at com.sun.xml.internal.ws.api.server.WSEndpoint.create(Unknown Source)
at com.sun.xml.internal.ws.transport.http.server.EndpointImpl.createEndpoint(Unknown Source)
at com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(Unknown Source)
at com.mirth.connect.connectors.ws.WebServiceMessageReceiver.doConnect(WebServiceMessageReceiver.java:125)
at org.mule.providers.AbstractMessageReceiver.connect(AbstractMessageReceiver.java:355)
... 26 more
The channel I used worked perfectly at Mirth 1.8, but when I deployed it in 2.0 it kept getting this error, and I had checked with netstat to make sure the port i used wasn't occupied. I've tried adding JAXWS and JAXB to the custom-lib but it's also not working (tried this solution from the Mirth Support forum). One more thing, I used the default service for the Web Service Listener. Any idea how to solve this?
Thanks in advance
extra note: I haven't uninstall the 1.8 version yet, since it is still used by the current program my company developed.
I know this is kind of old but I figured I'd answer it anyway. I think this is the same issue my team encountered:
There was an issue in Mirth 2.0 -- after the service is restarted or the machine rebooted, it tries to contact the WSDL one time. If your WSDL is not discoverable, you get this error deploying the channels.
We verbally confirmed with Mirth's support team that it was a known issue but unfortunately I can't find it in their issue tracker. I don't know if it's fixed. I would try with the latest version, or alternately make sure your WSDL can be found by Mirth.