I'm attempting to track this issue with HP's Enterprise Support as well, but am not familiar with Java's RMI context, and am hoping the community can provide some assistance, too.
Context: recently upgraded the reporting tool for HP's BSA (Business Service Automation) Suite from SAR (Service Automation Reporting) 7.81 to BSAE (BSA Essentials) 2.0.
In the process, one of the steps is to migrate previously-used external user authentication to the new reporting tool. When running that migration script, the following Java error stack is dumped:
14:57:25,316 DEBUG [InvokeCommand] Using params: /var/opt/opsware/omdb/tmp/sar-aaa-migrate-1279033044903.xml
14:57:26,512 ERROR [Twiddle] Exec failed
java.rmi.UnmarshalException: Error unmarshaling return; nested exception is:
java.lang.ClassNotFoundException: com.opsware.cmdb.security.data.AAADataImportException (no security manager: RMI class loader disabled)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:227)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy0.invoke(Unknown Source)
at org.jboss.console.twiddle.command.InvokeCommand.invoke(InvokeCommand.java:235)
at org.jboss.console.twiddle.command.InvokeCommand.execute(InvokeCommand.java:291)
at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:306)
Caused by: java.lang.ClassNotFoundException: com.opsware.cmdb.security.data.AAADataImportException (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:225)
... 13 more
Understanding that I have 0 access to the code base, is there a place I can start to look for what may be causing the RMI failures, or will this need to be handled exclusively through the vendor?
Thanks for any assistance/pointers!
Turns out the root cause on this error is related to issues with both the documented upgrade process from SAR to BSAE and the dataminer on the HPSA server attempting to re-mine the same data chunks over and over again.
The fix for this is to do a complete back-out of BSAE to a blank server, then doing a clean install.
Sadly, that means all historical data is lost in the process :-|
Related
I'm trying to follow the example project "Feedback" from Continuous Enterprise Development in Java, ch. 3 with a bit of modification.
I am using IntelliJ Idea and its JBoss-Forge plugin which shouldn't differ from using the console like in the book.
So far I've created a new project with the following characteristics:
Java 1.8
JEE 7
Wildfly 10.1.0.Final
JUnit 4.12
Arquillian 1.1.13.0
Hibernate
Maven profile: arquillian-wildfly-remote
I've followed every step from the tutorial, all using the IntelliJ plugin:
set ACCEPT_DEFAULTS true
created the project
set up persistence with Hibernate
set up validation with Hibernate validator
created entity FeedbackEntry
scaffolded the UI
forge install-plugin arquillian
set up Arquillian with Wildfly remote container
created an Arquillian
built and deploy the app
All of them ended successfully, I can open the UI and store some values in the DB. The problem comes when trying to run the test: I create an Wildfly Remote Arquillian container:
After clicking OK this is the stacktrace I get:
java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:166)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:103)
at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:114)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:162)
... 8 more
Caused by: org.jboss.arquillian.container.impl.ContainerCreationException: Could not create Container arquillian-wildfly-remote
at org.jboss.arquillian.container.impl.LocalContainerRegistry.create(LocalContainerRegistry.java:85)
at org.jboss.arquillian.container.impl.client.container.ContainerRegistryCreator.createRegistry(ContainerRegistryCreator.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.ManagerImpl.bindAndFire(ManagerImpl.java:263)
at org.jboss.arquillian.core.impl.InstanceImpl.set(InstanceImpl.java:74)
at org.jboss.arquillian.config.impl.extension.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.ManagerImpl.start(ManagerImpl.java:288)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.<init>(EventTestRunnerAdaptor.java:63)
... 13 more
Caused by: java.lang.IllegalStateException: Multiple service implementations found for interface org.jboss.arquillian.container.spi.client.container.DeployableContainer. org.jboss.as.arquillian.container.remote.RemoteDeployableContainer, org.arquillian.container.chameleon.ChameleonContainer
at org.jboss.arquillian.core.impl.loadable.ServiceRegistryLoader.onlyOne(ServiceRegistryLoader.java:74)
at org.jboss.arquillian.container.impl.LocalContainerRegistry.create(LocalContainerRegistry.java:76)
... 37 more
Test ignored.
Test ignored.
Process finished with exit code 255
I've searched in many places and I only have found this. However I don't think I have more than 1 container, only Wildfly, so I'm completely clueless about this.
Pom and other key files here: https://gist.github.com/josemigallas/a139fc601b022356391fad5b2ec588b0
Why is this failing and how can I solve/workaround this issue?
From my experience, it might be an issue with Arquillian Plugin or IDEA Maven support having troubles with activating the profile. Please make sure that arquillian-wildfly-remote is in fact enabled by default (if it's ticked then untick and tick it again :)). Also run the test using regular JUnit runner, not the Arquillian one.
I think this is a problem when using IntelliJ with Arquillian support. Can you try to run it from CLI?
When a .wlapp file is deployed in MobileFirst Console, we get the following error in the logs. This happened after we upgraded MobileFirst Server from 6.3 to 7, but don't know if this is related to the version of MobileFirst.
000001c6 BaseTransacti E RuntimeMBeanCallable.call() exception
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy166.deployApplication(Unknown Source)
at com.ibm.worklight.admin.actions.ApplicationDeploymentTransaction.prepareMBean(ApplicationDeploymentTransaction.java:919)
at com.ibm.worklight.admin.actions.util.RuntimeMBeanWorkerThreadCaller$RuntimeMBeanCallable.call(RuntimeMBeanWorkerThreadCaller.java:76)
at com.ibm.worklight.admin.actions.util.RuntimeMBeanWorkerThreadCaller.callSynchronously(RuntimeMBeanWorkerThreadCaller.java:183)
at com.ibm.worklight.admin.actions.util.RuntimeMBeanPoolCaller.callRuntimeMBeans(RuntimeMBeanPoolCaller.java:91)
at com.ibm.worklight.admin.actions.BaseTransaction.prepare(BaseTransaction.java:450)
at com.ibm.worklight.admin.actions.BaseTransaction.internalRun(BaseTransaction.java:348)
at com.ibm.worklight.admin.actions.BaseTransaction$1.run(BaseTransaction.java:235)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:790)
Caused by: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: The system failed to make the SOAP RPC call: invoke
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:894)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:689)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:679)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:665)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:487)
at com.sun.proxy.$Proxy121.invoke(Unknown Source)
at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
at com.worklight.common.util.jmx.WASRuntimeMBeanHandler$AdminClientMBeanServerConnection.invoke(WASRuntimeMBeanHandler.java:521)
at com.sun.jmx.mbeanserver.MXBeanProxy$InvokeHandler.invoke(MXBeanProxy.java:146)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:160)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:246)
... 11 more
Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Read timed out; targetException=java.net.SocketTimeoutException: Read timed out]
at org.apache.soap.transport.http.SOAPHTTPConnection.send(SOAPHTTPConnection.java:479)
at org.apache.soap.rpc.Call.WASinvoke(Call.java:510)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient$8.run(SOAPConnectorClient.java:852)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:845)
... 21 more
MobileFirst version 7
WAS server version 8.5.5.5
JRE version 1.6
Re-deploying the MobileFirst artifacts to the application server should normally not be required as inspecting the logs and configuration usually will lead to the root cause of the problem. However in some cases starting over to get things right will work.
As mentioned in the comments, re-deployment of the server artifacts nullified the issue that was experienced.
I have the following configuration:
Tomcat 7 gear running on OpenShift Online. I deployed Apache ODE as a webapp and tested a simple BPEL workflow (Echo test) that worked perfectly. I have 2 more gears on OpenShift both running WildFly8 servers and some web-services. I created a workflow for ODE that calles these services. When I test the workflow on my local PC running Tomcat 7 and Apache ODE it works just fine. However, on OpenShift I have the following issue:
When ODE tries to call a remote web-service it tells its Axis libraries to create a socket. Since binding sockets to "localhost" on OpenShift is not allowed, I get an exception. I modified the org.apache.commons.httpclient.HttpConnection.open() method to bind the socket to the local OpenShift IP of my gear instead of localhost and got rid of the bind exception. However, the remote web-service doesn't seem to respond to my request:
07:11:50,505 ERROR [ExternalService] Error sending message (mex={PartnerRoleMex#hqejbhcnphr9mgvfg5xbh1 [PID {org.neo}btest-2] calling org.apache.ode.bpel.epr.WSAEndpoint#1f51919.getClientData(...) Status ASYNC}): The host did not accept the connection within timeout of 60000 ms
org.apache.axis2.AxisFault: The host did not accept the connection within timeout of 60000 ms
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:203)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:76)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:400)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:225)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:438)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:402)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.apache.ode.axis2.SoapExternalService$1$1.call(SoapExternalService.java:206)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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:745)
Caused by: org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 60000 ms
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:155)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:715)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:557)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:199)
... 12 more
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
... 21 more
This is the article that gave me this idea: https://www.openshift.com/forums/openshift/commons-httpclient-permission-denied
Again, when testing the exact same workflow on my PC with the exact same web-services it works just fine, so the WildFly8 servers and web-services are not the issue.
I am grateful for any tips, I've been at this for almost a week now...
I managed to fix it by creating a DIY cartridge and installing the newest version of Tomcat 7 onto it. I deployed ODE and my workflow, got the same binding error as before, modified the apache-commons library that Axis was using and now it's sailing smoothly.
I don't know why it didn't work with the Tomcat 7 cartridge I get from OpenShift as standard though.
I'm trying to run my application in Idea using tc Server Idea plugin and receive the following log
Connected to server
wrapper | Starting the VMware vFabric tc Runtime instance - tcruntime-C-STS-vfabric-tc-server-developer-2.8.2.RELEASE-insight service...
wrapper | VMware vFabric tc Runtime instance - tcruntime-C-STS-vfabric-tc-server-developer-2.8.2.RELEASE-insight started.
[11:53:08.709] Not allowed to connect. Check role and password.
[11:53:08.709] There is an application at /bps. Starting redeploy...
[11:53:08.714] Not allowed to connect. Check role and password.
[11:53:08.715] Starting undeployment of /bps ...
[11:53:08.720] Not allowed to connect. Check role and password.
[11:53:08.721] Starting deployment of 'bps:war exploded' to /bps ...
[11:53:08.725] Not allowed to connect. Check role and password.
Can anybody describe what's the problem? I cann't fully understand how to config users and roles in tc Server.
UPDATE
The above problem is solved by enabling jmx. But now there is another problem
16-Apr-2013 14:36:36.023 SEVERE [RMI TCP Connection(4)-127.0.0.1] org.apache.tomcat.util.modeler.BaseModelMBean.invoke Exception invoking method deployApplication
java.lang.RuntimeException: Unable to find host
at com.springsource.tcserver.serviceability.deploy.TcContainerDeployer.deployApplication(TcContainerDeployer.java:409)
at com.springsource.tcserver.serviceability.deploy.TcContainerDeployer.deployApplication(TcContainerDeployer.java:399)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
at com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
at java.security.AccessController.doPrivileged(Native Method)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1426)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
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:722)
Rewriten CrazyCoders comment as answer:
I needed to check Run/Debug Configuration|Server tab|JMX authentification enabled.
Password and role could be found in: CATALINA_BASE/conf/jmxremote.password
I have a suggestion what host it's all about.
Part of tc Server deployment API is notion of service and host. There are some services, and each service contain some number of hosts. IDEA plugin provides by default Catalina service and localhost host. They are configured in Run/Debug Configuration | Deployment tab | Server service name and Server host name(you need to have something to deploy to see these settings).
Now how to get proper values. They are available via JMX. Connect with jconsole.exe from your JDK to service:jmx:rmi:///jndi/rmi://<your host>:<your port>/jmxrmi. It may need login and password you use for server's JMX. Then open tc server | Deployer | Operations in the tree in left panel. Operation getServices will list you available services, and getHosts will list you all hosts for selected service.
we have Sonar set up to run on a separate server. It does, and a client application (sonar-runner) can connect successfully to it. However, the run interrupts with the following exception:
Runner configuration file: C:\Program Files (x86)\sonar-runner-1.3\bin\..\conf\sonar-runner.properties
Project configuration file: C:\project\subproject\sonar-project.properties
Runner version: 1.3
Java version: 1.6.0_33, vendor: Sun Microsystems Inc.
OS name: "Windows 7", version: "6.1", arch: "x86"
Server: http://<serverip>:80
Work directory: C:\project\subproject\.sonar
Total time: 1:30.902s
Final Memory: 0M/15M
Exception in thread "main" org.sonar.batch.bootstrapper.BootstrapException: org.sonar.batch.bootstrapper.BootstrapException: Fail to download the file: http://<serverip>:80/batch/guava-10.0.1.jar
at org.sonar.batch.bootstrapper.Bootstrapper.downloadBatchFiles(Bootstrapper.java:164)
at org.sonar.batch.bootstrapper.Bootstrapper.createClassLoader(Bootstrapper.java:87)
at org.sonar.runner.Runner.createClassLoader(Runner.java:155)
at org.sonar.runner.Runner.execute(Runner.java:78)
at org.sonar.runner.Main.main(Main.java:61)
Caused by: org.sonar.batch.bootstrapper.BootstrapException: Fail to download the file: http://<serverip>:80/batch/guava-10.0.1.jar
at org.sonar.batch.bootstrapper.Bootstrapper.remoteContentToFile(Bootstrapper.java:113)
at org.sonar.batch.bootstrapper.Bootstrapper.downloadBatchFiles(Bootstrapper.java:159)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.ChunkedInputStream.readAheadBlocking(Unknown Source)
at sun.net.www.http.ChunkedInputStream.readAhead(Unknown Source)
at sun.net.www.http.ChunkedInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
at org.sonar.batch.bootstrapper.BootstrapperIOUtils.copyLarge(BootstrapperIOUtils.java:63)
at org.sonar.batch.bootstrapper.Bootstrapper.remoteContentToFile(Bootstrapper.java:109)
... 5 more
I can reproduce this with a normal browser. Retrieving the file opens the download manager, however, it takes up to 5 minutes until the file finally downloads (it's only 1.5 megs). Other files that are retrieved by the sonar-runner or using a browser do not have this problem.
The sonar logging doesn't seem to know that there is a problem. Downloads are not logged in the sonar.log file, neither successful ones nor the unsuccessful one. syslog doesn't contain any hints to problems.
had similar problem with sonar+php plugin and eset smart security. Had to disable filtering on 127.0.0.1 in filtering protocols section. It was happening randomly on different jars. It was happening on both solar ant task and solar runner
So, the solution was not something on the server, but rather a client-side problem. Kaspersky Endpoint Security seems to have a bug/feature that it needs to scan everything going over the network, and somehow this one JAR file triggered a multiple-minute-long delay while the file was being scanned.