App container instance (172.31.0.41) can't connect to DB container instance (172.31.0.38). See the following log detail:
... [INFO] cat.gencat.graelles.config.DatabaseConfiguration - Database URL: jdbc:mysql://172.31.0.38:3306/graelles ... Caused by: 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. ... Caused by: java.net.NoRouteToHostException: No route to host 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 com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:213) at com.mysql.jdbc.MysqlIO.(MysqlIO.java:297) ... 156 more
Perhaps there may be a network issue related to my account... or am I doing something wrong?
according to
https://www.ng.bluemix.net/docs/containers/container_single_ov.html#container_single_cli
a starting container will be able to use its network connections approximately 30 seconds after booting is complete, even if the reality suggests that (in this moment) you can be sure to have a working network interface after max 60 seconds.
Could you check that the error you are getting is happening only during the container's first seconds and after 60 seconds it works fine?
I have been suffering similar issue these past days and here are my findings: "java.net.NoRouteToHostException: No route to host" between two Docker Containers don't know if they can help you.
Related
After we setup PostgreSQL server with SSL certificates we get this error very often.
This happens on the flows with a lot of interaction with the database(update a lot of entries/insert)
HikariPool-1 - Connection marked as broken because of SQLSTATE(08006), ErrorCode(0)
j.n.SocketException: Connection reset by peer (Write failed)
at j.n.SocketOutputStream.socketWrite0(SocketOutputStream.java)
at j.n.SocketOutputStream.socketWrite(SocketOutputStream.java:110)
at j.n.SocketOutputStream.write(SocketOutpu`enter code here`tStream.java:150)
at s.s.s.SSLSocketOutputRecord.deliver(SSLSocketOutputRecord.java:320)
at s.s.s.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:983)
... 63 common frames omitted
Wrapped by: j.n.s.SSLProtocolException: Connection reset by peer (Write failed)
at s.security.ssl.Alert.createSSLException(Alert.java:126)
at s.s.s.TransportContext.fatal(TransportContext.java:321)
at s.s.s.TransportContext.fatal(TransportContext.java:264)
at s.s.s.TransportContext.fatal(TransportContext.java:259)
at s.s.s.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:988)
at j.i.BufferedOutputStream.write(BufferedOutputStream.java:123)
at j.i.FilterOutputStream.write(FilterOutputStream.java:108)
at o.p.core.PGStream.send(PGStream.java:252)
at o.p.c.v.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1440)
at o.p.c.v.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1767)
at o.p.c.v.QueryExecutorImpl.sendQuery(QueryExecutorImpl.java:1328)
at o.p.c.v.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
... 56 common frames omitted
Wrapped by: o.p.u.PSQLException: An I/O error occurred while sending to the backend
I was able to solve this issue by adding below properties:
spring.datasource.test-while-idle=true
spring.datasource.validation-query=SELECT 1;
spring.datasource.time-between-eviction-runs-millis=60000
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.validationTimeout=300000
spring.datasource.remove-abandoned=true
spring.datasource.remove-abandoned-timeout=60
spring.datasource.hikari.connectionTimeout=30000
spring.datasource.hikari.idleTimeout=600000
spring.datasource.hikari.maxLifetime=1800000
Fixed the problem by updating jdk version from 11.0.2 to 11.0.5. Related to
JDK-8221253 TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 bytes
I have OrienDB 2.1.4 cluster of 3 nodes with basic configuration. The only change in hazelcast.xml I made is to replace multicast by implicit tcp-ip hosts list.
After heavy request to DB (select without joins, about 300k rows in result set), OrientDB stops response to network connection attempts from application (OrientDB Studio is still working), the follwoing exceptions continuously appear in logs:
on master node
2016-02-24 10:02:17:647 INFO [10.10.10.124]:2434 [zertodb] [3.3.5] Remaining migration tasks in queue => 1 [InternalPartitionService][10.10.10.124]:2434 [zertodb] [3.3.5] Received data format is invalid. (An old version of Hazelcast may be running here.)
com.hazelcast.nio.serialization.HazelcastSerializationException: java.io.UTFDataFormatException: Length check failed, maybe broken bytestream or wrong stream position
at com.hazelcast.nio.serialization.SerializationServiceImpl.handleException(SerializationServiceImpl.java:354)
at com.hazelcast.nio.serialization.SerializationServiceImpl.readObject(SerializationServiceImpl.java:341)
at com.hazelcast.nio.serialization.ByteArrayObjectDataInput.readObject(ByteArrayObjectDataInput.java:454)
at com.hazelcast.cluster.MulticastService.receive(MulticastService.java:155)
at com.hazelcast.cluster.MulticastService.run(MulticastService.java:113)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.UTFDataFormatException: Length check failed, maybe broken bytestream or wrong stream position
at com.hazelcast.nio.UTFEncoderDecoder.readUTF0(UTFEncoderDecoder.java:505)
at com.hazelcast.nio.UTFEncoderDecoder.readUTF(UTFEncoderDecoder.java:77)
at com.hazelcast.nio.serialization.ByteArrayObjectDataInput.readUTF(ByteArrayObjectDataInput.java:450)
at com.hazelcast.cluster.ConfigCheck.readData(ConfigCheck.java:219)
at com.hazelcast.cluster.JoinMessage.readData(JoinMessage.java:80)
at com.hazelcast.cluster.JoinRequest.readData(JoinRequest.java:64)
at com.hazelcast.nio.serialization.DataSerializer.read(DataSerializer.java:111)
at com.hazelcast.nio.serialization.DataSerializer.read(DataSerializer.java:39)
at com.hazelcast.nio.serialization.StreamSerializerAdapter.read(StreamSerializerAdapter.java:44)
at com.hazelcast.nio.serialization.SerializationServiceImpl.readObject(SerializationServiceImpl.java:335)
... 4 more
on other nodes:
[10.10.10.194]:2434 [zertodb] [3.3.5] Received data format is invalid. (An old version of Hazelcast may be running here.)
com.hazelcast.nio.serialization.HazelcastSerializationException: java.io.StreamCorruptedException: invalid type code: 00
at com.hazelcast.nio.serialization.SerializationServiceImpl.handleException(SerializationServiceImpl.java:354)
at com.hazelcast.nio.serialization.SerializationServiceImpl.readObject(SerializationServiceImpl.java:341)
at com.hazelcast.nio.serialization.ByteArrayObjectDataInput.readObject(ByteArrayObjectDataInput.java:454)
at com.hazelcast.cluster.ConfigCheck.readData(ConfigCheck.java:215)
at com.hazelcast.cluster.JoinMessage.readData(JoinMessage.java:80)
at com.hazelcast.cluster.JoinRequest.readData(JoinRequest.java:64)
at com.hazelcast.nio.serialization.DataSerializer.read(DataSerializer.java:111)
at com.hazelcast.nio.serialization.DataSerializer.read(DataSerializer.java:39)
at com.hazelcast.nio.serialization.StreamSerializerAdapter.read(StreamSerializerAdapter.java:44)
at com.hazelcast.nio.serialization.SerializationServiceImpl.readObject(SerializationServiceImpl.java:335)
at com.hazelcast.nio.serialization.ByteArrayObjectDataInput.readObject(ByteArrayObjectDataInput.java:454)
at com.hazelcast.cluster.MulticastService.receive(MulticastService.java:155)
at com.hazelcast.cluster.MulticastService.run(MulticastService.java:113)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.StreamCorruptedException: invalid type code: 00
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1379)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at com.hazelcast.nio.serialization.DefaultSerializers$ObjectSerializer.read(DefaultSerializers.java:196)
at com.hazelcast.nio.serialization.StreamSerializerAdapter.read(StreamSerializerAdapter.java:44)
at com.hazelcast.nio.serialization.SerializationServiceImpl.readObject(SerializationServiceImpl.java:335)
... 12 more
The same query with smaller result set works fine.
I have found this issue https://github.com/hazelcast/hazelcast/issues/4327 about your problem with hazelcast.
Hope it helps.
I'm experiencing intermittent connectivity errors from a Spring Boot application communicating with a D1 Google CloudSQL Server with the configuration settings described here HikariCP MySQL settings
I was wondering if anyone has encountered this before.
I've read the FAQ posted here Hikari FAQ and I'm wondering if my default idleTimeout and maxLifeTime (30 mins) settings might be at fault; wait_timeout and interactive_timeout on the server are both set to default 28800s (8 hours).
The FAQ says that these two settings should be about a minute less that the server settings, but if I'm losing connections after 30 minutes I can't quite see how upping the maxLifeTime to 7hrs 59mins is going to improve the situation.
Does anyone have any recommendations?
Redacted stack trace(s):
Get these from time to time
org.springframework.security.authentication.InternalAuthenticationServiceException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Timeout after 30018ms of waiting for a connection.
at org.springframework.security.authentication.dao.DaoAuthenticationProvider.retrieveUser(DaoAuthenticationProvider.java:110)
at org.springframework.security.authentication.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:132)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:177)
...
Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Timeout after 30023ms of waiting for a connection.
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80)
....
Caused by: java.sql.SQLException: Timeout after 30023ms of waiting for a connection.
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:208)
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:108)
at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
... 59 common frames omitted
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:630)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:695)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:727)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:737)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:787)
Hibernate search:
2015-02-17 10:34:17.090 INFO 1 --- [ entityloader-2] o.h.s.i.SimpleIndexingProgressMonitor : HSEARCH000030: 31050 documents indexed in 1147865 ms
2015-02-17 10:34:17.090 INFO 1 --- [ entityloader-2] o.h.s.i.SimpleIndexingProgressMonitor : HSEARCH000031: Indexing speed: 27.050219 documents/second; progress: 99.89%
2015-02-17 10:41:59.917 WARN 1 --- [ntifierloader-1] com.zaxxer.hikari.proxy.ConnectionProxy : Connection com.mysql.jdbc.JDBC4Connection#372f2018 (HikariPool-0) marked as broken because of SQLSTATE(08S01), ErrorCode(0).
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 1,611,087 milliseconds ago. The last packet sent successfully to the server was 927,899 milliseconds ago.
The indexing isn't particularly quick at the moment I think because I'm not using projections. The process takes about 30 minutes to execute.
Thanks
It could be a couple of things here. First, the network infrastructure (firewalls, load-balancers, etc.) between the application tier and the database tier can impose their own connection timeouts, regardless of MySql settings.
The indexing failure indicates that the connection was out of the pool for ~27 minutes with no SQL activity when that failure occurred.
Second, specifically regarding the "Could not get JDBC Connection" error, you may be running into Cloud SQL connection limits.
I recommend three things. One, make sure you are on the latest HikariCP (2.3.2) and latest MySql Connector/J driver (5.1.34). Two, enable DEBUG-level logging for the com.zaxxer.hikari package. HikariCP debug logging is not "chatty", but will log pool statistics every 30 seconds (and sometimes more detail in failure conditions). Lastly, try setting the maxPoolSize to something smaller (unless already at the default), and setting maxLifeTime to 15 or 20 minutes (1200000ms).
If the error occurs again, post updated logs containing the HikariCP debug logs around the time of failure. Also, feel free to open a tracking issue over on Github as larger logs etc. are easier there.
I am new to scalatest and when I finished the project I add a test file.
Is there any place that I should particularly pay attention to?
I met this problem when I want to run a unitest in intelli idea
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:50594,suspend=y,server=n -Dfile.encoding=UTF-8 -classpath "/Users/xuyin/Library/Application Support/IdeaIC13/Scala/lib/scala-plugin-runners.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/javafx-doclet.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/htmlconverter.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/JObjC.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Users/xuyin/codebase/api-server/target/scala-2.10/test-classes:/Users/xuyin/codebase/api-server/target/scala-2.10/classes:/Users/xuyin/.sbt/boot/scala-2.10.1/lib/scala-library.jar:/Users/xuyin/.ivy2/cache/com.typesafe.slick/slick_2.10/jars/slick_2.10-1.0.0.jar:/Users/xuyin/.ivy2/cache/org.slf4j/slf4j-api/jars/slf4j-api-1.6.4.jar:/Users/xuyin/.ivy2/cache/org.slf4j/slf4j-nop/jars/slf4j-nop-1.6.4.jar:/Users/xuyin/.ivy2/cache/com.h2database/h2/jars/h2-1.3.166.jar:/Users/xuyin/.ivy2/cache/mysql/mysql-connector-java/jars/mysql-connector-java-5.1.13.jar:/Users/xuyin/.ivy2/cache/org.scalaquery/scalaquery_2.9.1-1/jars/scalaquery_2.9.1-1-0.10.0-M1.jar:/Users/xuyin/.ivy2/cache/com.twitter/finagle-core_2.10/jars/finagle-core_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/io.netty/netty/bundles/netty-3.5.5.Final.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-core_2.10/jars/util-core_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-collection_2.10/jars/util-collection_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.google.guava/guava/jars/guava-13.0.1.jar:/Users/xuyin/.ivy2/cache/com.google.guava/guava/jars/guava-11.0.2.jar:/Users/xuyin/.ivy2/cache/commons-collections/commons-collections/jars/commons-collections-3.2.1.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-hashing_2.10/jars/util-hashing_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-jvm_2.10/jars/util-jvm_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-logging_2.10/jars/util-logging_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-app_2.10/jars/util-app_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/finagle-http_2.10/jars/finagle-http_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-codec_2.10/jars/util-codec_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/commons-codec/commons-codec/jars/commons-codec-1.6.jar:/Users/xuyin/.ivy2/cache/commons-codec/commons-codec/jars/commons-codec-1.5.jar:/Users/xuyin/.ivy2/cache/commons-lang/commons-lang/jars/commons-lang-2.6.jar:/Users/xuyin/.ivy2/cache/com.twitter/finagle-ostrich4_2.10/jars/finagle-ostrich4_2.10-6.2.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/ostrich_2.10/jars/ostrich_2.10-9.1.0.jar:/Users/xuyin/.ivy2/cache/com.twitter/util-eval_2.10/jars/util-eval_2.10-6.1.0.jar:/Users/xuyin/.sbt/boot/scala-2.10.1/lib/scala-compiler.jar:/Users/xuyin/.ivy2/cache/org.scala-lang/scala-reflect/jars/scala-reflect-2.10.1.jar:/Users/xuyin/.ivy2/cache/com.twitter/scala-json_2.10/jars/scala-json_2.10-3.0.1.jar:/Users/xuyin/.ivy2/cache/net.liftweb/lift-json_2.10/jars/lift-json_2.10-2.5.jar:/Users/xuyin/.ivy2/cache/org.scala-lang/scalap/jars/scalap-2.10.0.jar:/Users/xuyin/.ivy2/cache/com.thoughtworks.paranamer/paranamer/jars/paranamer-2.4.1.jar:/Users/xuyin/.ivy2/cache/log4j/log4j/bundles/log4j-1.2.16.jar:/Users/xuyin/.ivy2/cache/log4j/log4j/jars/log4j-1.2.14.jar:/Users/xuyin/.ivy2/cache/com.github.sgroschupf/zkclient/jars/zkclient-0.1.jar:/Users/xuyin/.ivy2/cache/org.apache.zookeeper/zookeeper/jars/zookeeper-3.3.3.jar:/Users/xuyin/.ivy2/cache/jline/jline/jars/jline-0.9.94.jar:/Users/xuyin/.ivy2/cache/junit/junit/jars/junit-3.8.1.jar:/Users/xuyin/.ivy2/cache/org.scalatest/scalatest_2.10/jars/scalatest_2.10-1.9.1.jar:/Users/xuyin/.ivy2/cache/org.scala-lang/scala-actors/jars/scala-actors-2.10.0.jar:/Users/xuyin/.ivy2/cache/com.github.tomakehurst/wiremock/jars/wiremock-1.33.jar:/Users/xuyin/.ivy2/cache/net.sf.jopt-simple/jopt-simple/jars/jopt-simple-4.3.jar:/Users/xuyin/.ivy2/cache/com.fasterxml.jackson.core/jackson-core/jars/jackson-core-2.1.2.jar:/Users/xuyin/.ivy2/cache/org.mortbay.jetty/jetty/jars/jetty-6.1.26.jar:/Users/xuyin/.ivy2/cache/org.mortbay.jetty/jetty-util/jars/jetty-util-6.1.26.jar:/Users/xuyin/.ivy2/cache/org.mortbay.jetty/servlet-api/jars/servlet-api-2.5-20081211.jar:/Users/xuyin/.ivy2/cache/com.jayway.jsonpath/json-path/bundles/json-path-0.8.1.jar:/Users/xuyin/.ivy2/cache/net.minidev/json-smart/jars/json-smart-1.1.1.jar:/Users/xuyin/.ivy2/cache/org.apache.httpcomponents/httpclient/jars/httpclient-4.2.3.jar:/Users/xuyin/.ivy2/cache/org.apache.httpcomponents/httpcore/jars/httpcore-4.2.2.jar:/Users/xuyin/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.1.1.jar:/Users/xuyin/.ivy2/cache/com.fasterxml.jackson.core/jackson-annotations/jars/jackson-annotations-2.1.2.jar:/Users/xuyin/.ivy2/cache/junit/junit-dep/jars/junit-dep-4.10.jar:/Users/xuyin/.ivy2/cache/com.fasterxml.jackson.core/jackson-databind/jars/jackson-databind-2.1.2.jar:/Applications/IntelliJ IDEA 13 CE.app/lib/idea_rt.jar" org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestRunner -s com.umeng.push.apiserver.ApiServerServiceSpec -showProgressMessages true -C org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestReporter
Testing started at PM12:49 ...
Connected to the target VM, address: '127.0.0.1:50594', transport: 'socket'
Exception encountered when invoking run on a nested suite - java.net.BindException: Permission denied
java.lang.RuntimeException: java.net.BindException: Permission denied
at com.github.tomakehurst.wiremock.WireMockServer.start(WireMockServer.java:168)
at com.umeng.push.apiserver.ApiServerServiceSpec.beforeAll(ApiServerServiceSpec.scala:33)
at org.scalatest.BeforeAndAfterAll$class.beforeAll(BeforeAndAfterAll.scala:150)
at com.umeng.push.apiserver.ApiServerServiceSpec.beforeAll(ApiServerServiceSpec.scala:26)
at org.scalatest.BeforeAndAfterAll$class.run(BeforeAndAfterAll.scala:211)
at com.umeng.push.apiserver.ApiServerServiceSpec.run(ApiServerServiceSpec.scala:26)
at org.scalatest.tools.SuiteRunner.run(SuiteRunner.scala:60)
at org.scalatest.tools.Runner$$anonfun$doRunRunRunDaDoRunRun$3.apply(Runner.scala:1604)
at org.scalatest.tools.Runner$$anonfun$doRunRunRunDaDoRunRun$3.apply(Runner.scala:1601)
at scala.collection.immutable.List.foreach(List.scala:318)
at org.scalatest.tools.Runner$.doRunRunRunDaDoRunRun(Runner.scala:1601)
at org.scalatest.tools.Runner$$anonfun$runOptionallyWithPassFailReporter$2.apply(Runner.scala:705)
at org.scalatest.tools.Runner$$anonfun$runOptionallyWithPassFailReporter$2.apply(Runner.scala:704)
at org.scalatest.tools.Runner$.withClassLoaderAndDispatchReporter(Runner.scala:1645)
at org.scalatest.tools.Runner$.runOptionallyWithPassFailReporter(Runner.scala:703)
at org.scalatest.tools.Runner$.run(Runner.scala:592)
at org.scalatest.tools.Runner.run(Runner.scala)
at org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestRunner.runScalaTest1(ScalaTestRunner.java:213)
at org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestRunner.main(ScalaTestRunner.java:37)
Caused by: java.net.BindException: Permission denied
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376)
at java.net.ServerSocket.bind(ServerSocket.java:376)
at java.net.ServerSocket.<init>(ServerSocket.java:237)
at java.net.ServerSocket.<init>(ServerSocket.java:181)
at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:80)
at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73)
at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:283)
at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.Server.doStart(Server.java:235)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at com.github.tomakehurst.wiremock.WireMockServer.start(WireMockServer.java:166)
... 18 more
Disconnected from the target VM, address: '127.0.0.1:50594', transport: 'socket'
Process finished with exit code 0
Jetty is probably trying to open a restricted port (like 80), and you are not running as root. Check the port number your test code is telling it to use (or it might be using a default).
I had a similar problem when I was using a USB surf stick for connecting to the internet, with some provider specific software to operate the surf stick. When disconnecting the stick (and thereby disconnecting from the internet), debugging worked fine for me. The stick software somehow messed up the routing of my computer, such that it tried to connect to localhost via the stick, which failed because the port number was blocked.
So, check if you have a similar configuration, and if it works when you turn off your internet connection.
Alternatively, this might also be a firewall issue. Try turning off your firewall for a while.
I strongly recommend disconnecting from the internet while your firewall is turned off!
After starting the run/debug configuration begins build and deploy application. All goes well. The only thing that provides continuously JBoss Log SocketException:
2012-07-16 12:43:30,424 DEBUG [org.jboss.naming.Naming] Error writing response to /127.0.0.1 java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1847) at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1756) at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1257) at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1211) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1395) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1547) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:333) at org.jnp.server.Main$BootstrapRequestHandler.run(Main.java:516) at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:148) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756) at java.lang.Thread.run(Thread.java:662)
At issues.jboss.org/browse/JBAS-3417 offer a solution:
If you set server / etc / host with:
IP fqn name
where IP is in «Error writing response to / IP"
Ex:
... "Error writing response to / 10.1.0.1"
10.1.0.1 test.mydomain test
you resolve the problem
But I have something 127.0.0.1 localhost, it is already registered in the default c:\ Windows\system32\drivers\etc\hosts
In the Troubleshooting says:
You may notice something in the JBoss logs similar to the following:
2009-01-28 08:36:57,381 DEBUG
[org.jboss.naming.NamingService]
Error writing response to / 127.0.0.1 <[http://127.0.0.1]>
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0 (Native Method)
This is most likely an anomalous and benign «problem». That is, it should not affect the operation of any applications deployed to JBoss.
If this does not affect deployed application can be any way to hide it? And then the continuous output overshadows the other posts and eats memory.