2014-01-02 5 views
4

Я знаю, что это дублированный вопрос. Но я не мог найти решение для этого же.PostgreSQL Исключение: org.postgresql.util.PSQLException: Ошибка ввода-вывода при отправке на бэкенд

Я разместил свое приложение в облаке Amazon EC2. И я использую postgresql.

Я получаю исключение org.postgresql.util.PSQLException: An I/O error occured while sending to the backend. при запуске приложения в Amazon cloud.

Подробный стек трассировки:

org.postgresql.util.PSQLException: An I/O error occured while sending to the backend. 
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:281) 
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555) 
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403) 
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:331) 
    at com.spy2k3.core.business.processor.ProcessorImpl.executeUpdate(ProcessorImpl.java:237) 
    at com.spy2k3.core.business.object.BusinessObject.executeUpdate(BusinessObject.java:54) 
    at com.spy2k3.core.business.object.LoginObject.deleteSession(LoginObject.java:127) 
    at com.spy2k3.core.business.processor.LoginProcessor.userValidation(LoginProcessor.java:79) 
    at com.spy2k3.core.business.processor.LoginProcessor.execute(LoginProcessor.java:30) 
    at com.spy2k3.core.business.processor.ProcessorImpl.process(ProcessorImpl.java:73) 
    at com.spy2k3.core.handler.request.RequestHandler.doService(RequestHandler.java:90) 
    at com.spy2k3.core.handler.AbstractHandler.doPost(AbstractHandler.java:25) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) 
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) 
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) 
    at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) 
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) 
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) 
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) 
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) 
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 
    at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) 
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) 
    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) 
    at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) 
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) 
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) 
    at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) 
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) 
    at java.lang.Thread.run(Thread.java:662) 
Caused by: java.net.SocketException: Socket closed 
    at java.net.SocketInputStream.socketRead0(Native Method) 
    at java.net.SocketInputStream.read(SocketInputStream.java:129) 
    at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:143) 
    at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:112) 
    at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:71) 
    at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:269) 
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1700) 
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) 
    ... 37 more 

Тесты:

.Я подключил удаленный сервер PostgreSQL через PgAdmin из моей локальной системы, и я мог бы подключиться и выполнять запросы ,

. Я подключился к удаленному серверу с помощью шпатлевки и смог успешно выполнить запросы. Пример:

[[email protected] bin]# psql -U myuser -d mydatabase 
    psql (9.2.4) 
    Type "help" for help. 

mydatabase=# SELECT USERID FROM MY_MAST_LOGINSESSION WHERE SESSIONID='5DFD5D1E09D523695D6057SOMETHING'; 
userid 
-------- 
(0 rows) 

.Когда я подключил удаленную базу данных из моего приложения через JDBC, он успешно подключен, но это занимает слишком много времени, чтобы выполнить запросы там.

Можете ли вы предложить любое решение, чтобы узнать эту задержку?

UPDATE:

Во время углубляясь в проблему, я обнаружил, что задержка происходит только для конкретных запросов, таких как DELETE, UPDATE. Запросы, такие как INSERT, SELECT, выполняются отлично.

Специальность DELETE и UPDATE Запросы, которые ничего не возвращают.

Так что актуальной проблемой является запрос клиента (предположим, psql) ожидает ответа сервера базы данных, но для этих запросов сервер ничего не возвращает. Таким образом, клиент продолжает ждать, и после таймаута он выдает исключение.

Но я не смог найти, куда следует обратиться, чтобы решить эту проблему.

+1

Посмотрите на журнал ошибок сервера PostgreSQL ** на своем сервере, посмотрите, что он говорит об отключении. Лично я бы сказал, что у вас проблемы с подключением, учитывая задержки и прерывистые отключения. –

+0

Можете ли вы разместить свою строку соединения без ip-сервера и имени пользователя/пароля и метода, который запрашивает базу данных? – Arya

+0

@CraigRinger, Arya: Я обновил свой вопрос. –

ответ

4

Проблема была в параметре synchronous_standby_names в postgresql.conf.

В моем postgresql.conf это было synchronous_standby_names = '*'.

Когда я прокомментировал строку, я смог выполнить все запросы.

PostgreSQL documentation С:

synchronous_standby_names (строка): В любой момент времени будет не более одного активного синхронного режима ожидания; транзакции, ожидающие фиксации, будут разрешены для продолжения после того, как этот резервный сервер подтверждает получение их данных .

. , ,

Если не указано здесь нет синхронных резервных имен, затем синхронное репликации не включена и транзакция не будет ждать репликации.

Так актуальная проблема была:
клиент выполнение запроса (предположим, что PSQL) ждет ответа от сервера базы данных, но для этих запросов сервер ничего не возвращает, так как синхронная репликация была включена. Таким образом, клиент продолжал ждать, и после таймаута он выбросил исключение.

Смежные вопросы