Geen gegevens meer om uit socketfout te lezen

We gebruiken Oracle als de database voor onze webapplicatie. De applicatie werkt meestal goed, maar we krijgen de foutmelding “Geen gegevens meer om van socket te lezen”.

Caused by: java.sql.SQLRecoverableException: No more data to read from socket
    at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1142)
    at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1099)
    at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:288)
    at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
    at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:523)
    at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
    at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:863)
    at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1153)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1275)
    at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3576)
    at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3620)
    at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
    at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
    at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
    at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
    at org.hibernate.loader.Loader.getResultSet(Loader.java:1869)
    at org.hibernate.loader.Loader.doQuery(Loader.java:718)
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)
    at org.hibernate.loader.Loader.doList(Loader.java:2449)
    ... 63 more

We gebruiken spring, hibernate en ik heb het volgende voor de gegevensbron in mijn toepassingscontextbestand.

<bean class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close" id="dataSource">
        <property name="driverClassName" value="${database.driverClassName}" />
        <property name="url" value="${database.url}" />
        <property name="username" value="${database.username}" />
        <property name="password" value="${database.password}" />
        <property name="defaultAutoCommit" value="false" />
        <property name="initialSize" value="10" />
        <property name="maxActive" value="30" />
        <property name="validationQuery" value="select 1 from dual" />
        <property name="testOnBorrow" value="true" />
        <property name="testOnReturn" value="true" />
        <property name="poolPreparedStatements" value="true" />
        <property name="removeAbandoned" value="true" />
        <property name="logAbandoned" value="true" />
    </bean>

Ik weet niet zeker of dit komt door applicatiefouten, databasefouten of netwerkfouten.

We zien het volgende in de orakellogboeken

Thu Oct 20 10:29:44 2011
Errors in file d:\oracle\diag\rdbms\ads\ads\trace\ads_ora_3836.trc  (incident=31653):
ORA-03137: TTC protocol internal error : [12333] [4] [195] [3] [] [] [] []
Incident details in: d:\oracle\diag\rdbms\ads\ads\incident\incdir_31653\ads_ora_3836_i31653.trc
Thu Oct 20 10:29:45 2011
Trace dumping is performing id=[cdmp_20111020102945]
Thu Oct 20 10:29:49 2011
Sweep [inc][31653]: completed
Sweep [inc2][31653]: completed
Thu Oct 20 10:34:20 2011
Errors in file d:\oracle\diag\rdbms\ads\ads\trace\ads_ora_860.trc  (incident=31645):
ORA-03137: TTC protocol internal error : [12333] [4] [195] [3] [] [] [] []
Incident details in: d:\oracle\diag\rdbms\ads\ads\incident\incdir_31645\ads_ora_860_i31645.trc
Thu Oct 20 10:34:21 2011

Oracle-versie: 11.2.0.1.0

Antwoord 1, autoriteit 100%

Voor dergelijke fouten moet u Oracle-ondersteuning inschakelen. Helaas vermeld je niet welke orakelversie je gebruikt. De fout kan te maken hebben met het gluren van de optimizer. Afhankelijk van de orakelversie zijn er verschillende oplossingen van toepassing.

Je hebt twee manieren om dit aan te pakken:

• upgraden naar 11.2
• oracle-parameter instellen _optim_peek_user_binds = false

Natuurlijk mogen onderstrepingsparameters alleen worden ingesteld als dit wordt geadviseerd door de ondersteuning van Oracle

Antwoord 2, autoriteit 26%

We hadden hetzelfde probleem, we hebben het opgelost door de initialSizeen maxActivegrootte van de verbindingspool te vergroten.

U kunt dit controleren link

Misschien helpt dit iemand.

Antwoord 3, autoriteit 26%

Ander geval: als u datumparameters naar een geparametriseerde sql verzendt, zorg er dan voor dat u java.sql.Timestampheeft verzonden en niet java.util.Date. Anders krijg je

java.sql.SQLRecoverableException: geen gegevens meer om uit socket te lezen

Voorbeeldverklaring:
In onze Java-code gebruiken we org.apache.commons.dbutilsen we hebben het volgende:

final String sqlStatement = "select x from person where date_of_birth between ? and ?";
java.util.Date dtFrom = new Date(); //<-- this will fail
java.util.Date dtTo = new Date();   //<-- this will fail
Object[] params = new Object[]{ dtFrom , dtTo };
final List mapList = (List) query.query(conn, sqlStatement, new MapListHandler(),params); 

Het bovenstaande werkte niet totdat we de datumparameters veranderden in java.sql.Timestamp

java.sql.Timestamp tFrom = new java.sql.Timestamp (dtFrom.getTime()); //<-- this is OK
java.sql.Timestamp tTo = new java.sql.Timestamp(dtTo.getTime());   //<-- this is OK
Object[] params = new Object[]{ tFrom , tTo };
final List mapList = (List) query.query(conn, sqlStatement, new MapListHandler(),params); 

Antwoord 4, autoriteit 16%

Probeer twee dingen:

1. Stel $ORACLE_HOME/network/admin/tnsnames.ora in op de oracle server server=dedicated to server=shared om meer dan één verbinding tegelijk toe te staan. Herstart orakel.
2. Als je Java gebruikt, kan dit je misschien helpen: Verander in java/jdk1.6.0_31/jre/lib/security/Java.securitysecurerandom.source=file:/dev/urandomnaar securerandom.source=file:///dev/urandom

Antwoord 5, autoriteit 16%

Dit is een uitzondering op een zeer laag niveau, namelijk ORA-17410.

Het kan om verschillende redenen gebeuren:

1. Een tijdelijk probleem met netwerken.

2. Verkeerde JDBC-stuurprogrammaversie.

3. Enkele problemen met een speciale datastructuur (aan databasezijde).

4. Databasefout.

In mijn geval was het een bug die we op de database sloegen, die moet worden gepatched.

Antwoord 6, Autoriteit 13%

Ik had hetzelfde probleem. Ik was in staat om het probleem van de kant van het aanbrengen op te lossen, onder het volgende scenario:

JDK8, Veer Framework 4.2.4.Release, Apache Tomcat 7.0.63, Oracle-database 11G Enterprise Edition 11.2.0.4.0

Ik heb de database-aansluiting gebruikt Pooling apache tomcat-jdbc:

U kunt de volgende configuratieparameters innemen als referentie:

<Resource name="jdbc/exampleDB"
      auth="Container"
      type="javax.sql.DataSource"
      factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
      testWhileIdle="true"
      testOnBorrow="true"
      testOnReturn="false"
      validationQuery="SELECT 1 FROM DUAL"
      validationInterval="30000"
      timeBetweenEvictionRunsMillis="30000"
      maxActive="100"
      minIdle="10"
      maxWait="10000"
      initialSize="10"
      removeAbandonedTimeout="60"
      removeAbandoned="true"
      logAbandoned="true"
      minEvictableIdleTimeMillis="30000"
      jmxEnabled="true"
      jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
        org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer"
      username="your-username"
      password="your-password"
      driverClassName="oracle.jdbc.driver.OracleDriver"
      url="jdbc:oracle:thin:@localhost:1521:xe"/>

Deze configuratie was voldoende om de fout op te lossen. Dit werkt prima voor mij in het hierboven genoemde scenario.

Voor meer informatie over de Setup Apache Tomcat-JDBC: https: //tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

Antwoord 7, autoriteit 10%

Het downgraden van de JRE van 7 naar 6 loste dit probleem voor mij op.

Antwoord 8

Ja, zoals @ggkmath al zei, soms is een goede oude herstart precies wat je nodig hebt. Zoals wanneer “contact opnemen met de auteur en hem de app laten herschrijven, intussen wachten” geen optie is.

Dit gebeurt wanneer een applicatie (nog) niet zo is geschreven dat deze het herstarten van de onderliggende database aankan.

Antwoord 9

In ons geval hadden we een zoekopdracht die meerdere items laadt met select * from x waarbij iets in (…)
Het was gedeeltelijk zo lang voor benchmarktest. (17mb als tekstquery). Query is geldig, maar tekst zo lang. Het verkorten van de zoekopdracht loste het probleem op.

Antwoord 10

Ik leek mijn instantie te repareren door de tijdelijke aanduiding voor parameters voor een geparametriseerde query te verwijderen.

Om de een of andere reden werkte het gebruik van deze tijdelijke aanduidingen prima, en toen stopten ze met werken en kreeg ik de fout/bug.

Als tijdelijke oplossing heb ik mijn tijdelijke aanduidingen vervangen door letterlijke termen en het begon te werken.

Verwijder dit

where 
    SOME_VAR = :1

Gebruik dit

where 
    SOME_VAR = 'Value'

Antwoord 11

Ik kreeg deze fout en startte vervolgens mijn GlassFish-server opnieuw op die verbindingspools tussen mijn client-app en de database bevatte, en de fout ging weg. Probeer dus indien van toepassing uw applicatieserver opnieuw op te starten.