Postgres 11, receiving broken pipe, if stays inactive - postgresql

Spring application is logging broken pipe occasionally. To deal with stale connections issue, application is already using -
testWhileIdle=true and validationQuery=SELECT 1
Stack trace -
Caused by: org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:333)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)
at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:118)
at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.tomcat.jdbc.pool.StatementFacade$StatementProxy.invoke(StatementFacade.java:114)
at com.sun.proxy.$Proxy137.executeQuery(Unknown Source)
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:70)
... 133 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:115)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.postgresql.core.PGStream.flush(PGStream.java:514)
at org.postgresql.core.v3.QueryExecutorImpl.sendSync(QueryExecutorImpl.java:1363)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:304)
... 143 more
Caused by java.net.SocketException: Broken pipe (Write failed)
A vague feeling, if application stays inactive for while, then it might be giving problem connecting to backend or vice-versa. But since can not reproduce this issue locally, it is hard to point.

You can try setting the timeout of idle connection higher.
idle_in_transaction_session_timeout = 30000
in postgresql.conf
But your error seems strange to me. I would probably check if you dont have way to many connection as well.
On the spring-boot side you could try adding the following properties:
spring.datasource.test-on-borrow=true
spring.datasource.validation-query=SELECT 1
spring.datasource.validation-interval=30000
you could try reducing the validation interval. I set it to the default one there
Hope it helps

Related

Telemetry data unable to pass through root rule chain with node save timeseries

Things Board Version: V3.4.1 CE
OS: Window
Database: postgreSQL timescale
Queue: Rabbitmq
I discover that the telemetry data unable to pass through things board root rule chain with the node of the name save timeseries, i am not sure what is happening, i confirm there should be no problem on the connection between thingsboard and also postgreSQL...
I can see debug from here to know the problem is because failed to save to timeseries data....
2022-11-02 09:04:27,148 [sql-queue-2-ts timescale-11-thread-1] ERROR o.t.s.dao.sql.TbSqlBlockingQueue - [TS Timescale] Failed to save 2 entities
org.springframework.transaction.TransactionSystemException: Could not roll back JPA transaction; nested exception is org.hibernate.TransactionException: Unable to rollback against JDBC Connection
at org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:593)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:835)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:809)
at org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:672)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:392)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:708)
at org.thingsboard.server.dao.sqlts.insert.timescale.TimescaleInsertTsRepository$$EnhancerBySpringCGLIB$$693764a7.saveOrUpdate()
at org.thingsboard.server.dao.sqlts.timescale.TimescaleTimeseriesDao.lambda$init$1(TimescaleTimeseriesDao.java:89)
at org.thingsboard.server.dao.sql.TbSqlBlockingQueue.lambda$init$2(TbSqlBlockingQueue.java:74)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.hibernate.TransactionException: Unable to rollback against JDBC Connection
at org.hibernate.resource.jdbc.internal.AbstractLogicalConnectionImplementor.rollback(AbstractLogicalConnectionImplementor.java:127)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.rollback(JdbcResourceLocalTransactionCoordinatorImpl.java:304)
at org.hibernate.engine.transaction.internal.TransactionImpl.rollback(TransactionImpl.java:142)
at org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:589)
... 16 common frames omitted
Caused by: java.sql.SQLException: Connection is closed
at com.zaxxer.hikari.pool.ProxyConnection$ClosedConnection.lambda$getClosedConnection$0(ProxyConnection.java:515)
at com.sun.proxy.$Proxy153.rollback(Unknown Source)
at com.zaxxer.hikari.pool.ProxyConnection.rollback(ProxyConnection.java:396)
at com.zaxxer.hikari.pool.HikariProxyConnection.rollback(HikariProxyConnection.java)
at org.hibernate.resource.jdbc.internal.AbstractLogicalConnectionImplementor.rollback(AbstractLogicalConnectionImplementor.java:121)
... 19 common frames omitted
2022-11-02 09:04:27,148 [tb-rule-engine-consumer-37-thread-35 | QK(Main,TB_RULE_ENGINE,system)-10] INFO o.t.s.s.q.DefaultTbRuleEngineConsumerService - Failed to process 1 messages
2022-11-02 09:04:27,148 [tb-rule-engine-consumer-37-thread-35 | QK(Main,TB_RULE_ENGINE,system)-10] INFO o.t.s.s.q.DefaultTbRuleEngineConsumerService - [c1737420-58eb-11eb-808a-dfdc947dc52b] Failed to process message: TbMsg(queueName=Main, id=1318aa98-0755-49b0-9685-a71a2326ff7d, ts=1667351067141, type=POST_TELEMETRY_REQUEST, originator=354d8300-aa84-11ec-9a47-4727b3504d5d, customerId=d7094170-5c4c-11eb-b06a-c93fc5e45132, metaData=TbMsgMetaData(data={deviceType=Sensor, deviceName=RMS Voltage Sensor, ts=1667351067141}), dataType=JSON, data={"timestamp":1667351069011,"values":[{"id":"CnB Prai Gateway.RMS Shearline.Sensor5_Active","v":true,"t":1667291491472},{"id":"CnB Prai Gateway.RMS Shearline.Sensor5_Battery","v":296,"t":1667342191745},{"id":"CnB Prai Gateway.RMS Shearline.Sensor5_Signal","v":65478,"t":1667350910940},{"id":"CnB Prai Gateway.RMS Shearline.Sensor5_Voltage","v":0,"t":1667351068948}]}, ruleChainId=c1c082b0-58eb-11eb-808a-dfdc947dc52b, ruleNodeId=null, ctx=org.thingsboard.server.common.msg.TbMsgProcessingCtx#4c99aecc, callback=org.thingsboard.server.common.msg.queue.TbMsgCallback$1#415dca17), Last Rule Node: [RuleChain: Root Rule Chain|RuleNode: Save raw telemetry(71b87e70-177d-11ec-9530-3197ec48e7c5)]
I would suggest to use generator node to test where the problem is.
First you should test if you can save basic message (like the one you get when you open generator node). With this you will confirm that you can save data to database.
After that you should configure generator node to act as your device, and have same data and metadata as you would get from you device/integration.
Reach out back here with your findings from that.
Generator rule node ref: https://thingsboard.io/docs/user-guide/rule-engine-2-0/action-nodes/#generator-node

Testing Camunda REST API performance with SoapUI Pro - java.net.SocketTimeoutException: Read timed out

I'm running a load test on camunda BPM engine's REST API using SoapUI Pro 5.1.2 and I get about 10-30% of failures with the following exception.
Mon Mar 30 11:53:48 PDT 2015:ERROR:java.net.SocketTimeoutException: Read timed out
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:149)
at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:110)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:264)
at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:98)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247)
at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doReceiveResponse(HttpClientSupport.java:147)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:233)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:323)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:290)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:220)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.submitRequest(WsdlSubmit.java:80)
at com.eviware.soapui.impl.rest.RestRequest.submit(RestRequest.java:192)
at com.eviware.soapui.impl.wsdl.teststeps.RestTestRequestStep.run(RestTestRequestStep.java:793)
at com.eviware.soapui.impl.wsdl.support.AbstractTestCaseRunner.runTestStep(AbstractTestCaseRunner.java:213)
at com.eviware.soapui.impl.wsdl.testcase.WsdlTestCaseRunner.runCurrentTestStep(WsdlTestCaseRunner.java:47)
at com.eviware.soapui.impl.wsdl.support.AbstractTestCaseRunner.internalRun(AbstractTestCaseRunner.java:139)
at com.eviware.soapui.impl.wsdl.support.AbstractTestCaseRunner.internalRun(AbstractTestCaseRunner.java:47)
at com.eviware.soapui.impl.wsdl.support.AbstractTestRunner.run(AbstractTestRunner.java:129)
at com.eviware.soapui.impl.wsdl.loadtest.WsdlLoadTestRunner$InternalTestCaseRunner.run(WsdlLoadTestRunner.java:490)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Here's the load test scenario:
In my test case, I have a series of REST calls being done in sequence.
Load test attributes - Threads: 100, Startegy: Burst, Burst Delay: 10s, Burst Duration: 5s, Limit 1000 Total Runs.
I've tried setting the 'Socket Timeout' option of SoapUI to 300000 i.e 300 seconds and I see this is the only option I found on forums but I still get these errors. Also, as I mentioned, not all 1000 runs are failures, only 10-30 % of them fail randomly with this exception.
Sometimes, the load test succeeds with limiting the total runs to under 500 and even then, I get some of these errors and are occasional.
From the above trace, I understand the issue is at the client (SoupUI) side (or is my understanding not right?) and wanted to know how to get around this one?
If your process is synchronous the REST Call which starts the process will block until the process is completed. Which means if the process takes longer than your configured socket timeout the connection will be closed as no further data is expected on the socket. A solution would be to set the start event of your process to async so the REST call will immediately return. But I don't know if this fits your benchmark.
I've earlier set the socket timeout in the global settings of SoapUI but I found in a SmartBear forum that we have separate socket timeout option for the test case. It worked when I've set the timeout for the test case.

Spring MongoDB TCP connection ends then does a query

I am having a very strange problem with Spring 3.1 and MongoDB. I am using the Spring Mongo libs. This is a pretty simple call just pulls some data and inserts some new data. But as it is in the loop when pulling new data the connection is killed. From a capture I see it pull data insert data, then do another query but after a two second delay it sends a FIN packet to the server. the server then a little bit later tries to send data back to the client, but after that the client sends RSTs as it has already killed the connection.
Please let me know what other information I can provide to help understand this issue. I can provide a download link for the a capture file as well.
Thank you for your help
Trace output
org.springframework.dao.DataAccessResourceFailureException: can't call something : id561la.ytel.com/172.31.214.55:27017/cdrstat; nested exception is com.mongodb.MongoException$Network: can't call something : id561la.ytel.com/172.31.214.55:27017/cdrstat
at org.springframework.data.mongodb.core.MongoExceptionTranslator.translateExceptionIfPossible(MongoExceptionTranslator.java:56)
at org.springframework.data.mongodb.core.MongoTemplate.potentiallyConvertRuntimeException(MongoTemplate.java:1665)
at org.springframework.data.mongodb.core.MongoTemplate.executeFindMultiInternal(MongoTemplate.java:1548)
at org.springframework.data.mongodb.core.MongoTemplate.doFind(MongoTemplate.java:1336)
at org.springframework.data.mongodb.core.MongoTemplate.doFind(MongoTemplate.java:1322)
at org.springframework.data.mongodb.core.MongoTemplate.find(MongoTemplate.java:495)
at org.springframework.data.mongodb.core.MongoTemplate.find(MongoTemplate.java:486)
at dao.BaseMongoSQLDAO.queryForList(BaseMongoSQLDAO.java:35)
at dao.PrefixStatSqlMapDAO.list(PrefixStatSqlMapDAO.java:59)
at services.CDRReaderService.getPrefixStat(CDRReaderService.java:705)
at services.CDRReaderService.processFile(CDRReaderService.java:659)
at services.CDRReaderService.access$100(CDRReaderService.java:42)
at services.CDRReaderService$1.run(CDRReaderService.java:150)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
Caused by: com.mongodb.MongoException$Network: can't call something : id561la.ytel.com/172.31.214.55:27017/cdrstat
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:295)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:257)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:310)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:295)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at org.springframework.data.mongodb.core.MongoTemplate.executeFindMultiInternal(MongoTemplate.java:1534)
... 13 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:146)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at org.bson.io.Bits.readFully(Bits.java:46)
at org.bson.io.Bits.readFully(Bits.java:33)
at org.bson.io.Bits.readFully(Bits.java:28)
at com.mongodb.Response.<init>(Response.java:40)
at com.mongodb.DBPort.go(DBPort.java:124)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:286)
... 20 more

hornetq-2.3.0.Final. errors occurred when creating client connection.HornetQException[errorType=INTERNAL_ERROR message=null]

It happens very often to me .
We found it in development environment , most time we close the client process without close the client connection.
A simple way to replicate it , it just open 30+ client connections from remote host in seconds ,and kill the client Process.
so I think if I have 100 client connections from every application server to the HornetQ server , and one of the appserver crash , then no new client connections could be open any more.
after I started and stoped many client coonections , new Clients can't connect to Server .
I must restart the server .... thank you for help ..
on the Server side , the logs :
2013-07-06 15:31:01 [WARN ] org.hornetq.core.server
(ManagementServiceImpl.java:426) - HQ222111: exception while invoking
createTopic on jms.server java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.hornetq.core.server.management.impl.ManagementServiceImpl.invokeOperation(ManagementServiceImpl.java:843)
at org.hornetq.core.server.management.impl.ManagementServiceImpl.handleMessage(ManagementServiceImpl.java:418)
at org.hornetq.core.server.impl.ServerSessionImpl.handleManagementMessage(ServerSessionImpl.java:1513)
at org.hornetq.core.server.impl.ServerSessionImpl.send(ServerSessionImpl.java:1274)
at org.hornetq.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:445)
at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:631)
at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547)
at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523)
at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564)
at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72)
at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281)
at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169)
at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:555)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71)
at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73)
at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175)
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) Caused by: java.lang.NullPointerException
at org.hornetq.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:112)
at org.hornetq.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:453)
at org.hornetq.core.server.impl.HornetQServerImpl.createQueue(HornetQServerImpl.java:1850)
at org.hornetq.core.server.impl.HornetQServerImpl.deployQueue(HornetQServerImpl.java:1137)
at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateTopic(JMSServerManagerImpl.java:1280)
at org.hornetq.jms.server.impl.JMSServerManagerImpl.access$800(JMSServerManagerImpl.java:105)
at org.hornetq.jms.server.impl.JMSServerManagerImpl$2.runException(JMSServerManagerImpl.java:650)
at org.hornetq.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1832)
at org.hornetq.jms.server.impl.JMSServerManagerImpl.createTopic(JMSServerManagerImpl.java:637)
at org.hornetq.jms.management.impl.JMSServerControlImpl.createTopic(JMSServerControlImpl.java:481)
at org.hornetq.jms.management.impl.JMSServerControlImpl.createTopic(JMSServerControlImpl.java:470)
... 33 more 2013-07-06 15:31:01 [WARN ] org.hornetq.core.server (ServerSessionPacketHandler.java:541) -
Sending unexpected exception to the client
java.lang.NullPointerException
at org.hornetq.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:112)
Client:
Caused by: javax.jms.JMSException
at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:378)
at org.hornetq.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:1987)
at org.hornetq.core.client.impl.ClientSessionImpl.createTemporaryQueue(ClientSessionImpl.java:356)
at org.hornetq.core.client.impl.DelegatingSession.createTemporaryQueue(DelegatingSession.java:304)
at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:559)
at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:378)
at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:353)
at com.gamebean.toolkit.jms.hornetq.impl.MessageBridgeImpl.init(MessageBridgeImpl.java:89)
... 131 more Caused by: HornetQException[errorType=INTERNAL_ERROR message=null]
... 139 more

PostgreSQL PGCopyOutputStream dropped connection

I am facing an issue where my database connection seems to get dropped midway of a COPY command from jdbc (using PGCopyOutputStream). Any idea why this could be happening. I am writing into a table with two columns of integers. I am on PostgreSQL 9.0.3.
java.io.IOException: Write to copy failed.
at org.postgresql.copy.PGCopyOutputStream.write(PGCopyOutputStream.java:84) ~[postgresql-9.0-801.jdbc4.jar:na]
at org.postgresql.copy.PGCopyOutputStream.write(PGCopyOutputStream.java:76) ~[postgresql-9.0-801.jdbc4.jar:na]
at
...
...
Caused by: org.postgresql.util.PSQLException: Database connection failed when writing to copy
at org.postgresql.core.v3.QueryExecutorImpl.writeToCopy(QueryExecutorImpl.java:856) ~[postgresql-9.0-801.jdbc4.jar:na]
at org.postgresql.core.v3.CopyInImpl.writeToCopy(CopyInImpl.java:53) ~[postgresql-9.0-801.jdbc4.jar:na]
at org.postgresql.copy.PGCopyOutputStream.writeToCopy(PGCopyOutputStream.java:125) ~[postgresql-9.0-801.jdbc4.jar:na]
at org.postgresql.copy.PGCopyOutputStream.write(PGCopyOutputStream.java:82) ~[postgresql-9.0-801.jdbc4.jar:na]
... 10 common frames omitted
Caused by: java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:116) ~[na:1.7.0_03]
at java.net.SocketOutputStream.write(SocketOutputStream.java:153) ~[na:1.7.0_03]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) ~[na:1.7.0_03]
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:95) ~[na:1.7.0_03]
at org.postgresql.core.PGStream.SendChar(PGStream.java:174) ~[postgresql-9.0-801.jdbc4.jar:na]
at org.postgresql.core.v3.QueryExecutorImpl.writeToCopy(QueryExecutorImpl.java:850) ~[postgresql-9.0-801.jdbc4.jar:na]
... 13 common frames omitted
This was happening due to an earlier primary key constraint violation, that threw an exception and left the connection unusable.