This may help:
-----
— The Oozie server fails to reconnect JDBC connections after a DB restart.
Bug: None
Severity: Low
Anticipated resolution: Fixed in upcoming release
Workaround: The following configuration enables Oozie to discard stale
JDBC connections:
In the oozie-site.xml make the following changes to the JDBC URL
property oozie.service.StoreService.jdbc.url:
${ORIGINAL_JDBC_URL},TestOnBorrow=true,TestOnReturn=false,TestWhileIdle=false,
ValidationQuery=select count(*) from SLA_EVENTS
NOTE: The value shown above as ORIGINAL_JDBC_URL must be the JDBC URL
value that was in place previously for the same configuration name.
-----
Ref:
https://ccp.cloudera.com/display/CDHDOC/Known+Issues+and+Work+Arounds+in+CDH3#KnownIssuesandWorkAroundsinCDH3-Oozie
thx.
On Wed, May 16, 2012 at 7:56 AM, Harsh J <[email protected]> wrote:
> Hey Ken,
>
> Do you get this issue right from the start or did it pop up later? Did
> you also try the solution offered by the log itself? I recall having
> to do that once before to circumvent MySQL connectivity issues.
>
> On Wed, May 16, 2012 at 7:25 PM, Ken Ernst <[email protected]> wrote:
>> Hi,
>> Running oozie client build version: 2.3.2-cdh3u3 w/ MySQL as the store –
>> version 5.0.95. I am getting the below error.
>>
>> Exception, org.apache.oozie.store.StoreException: E0600: Could not get
>> connection, The last packet successfully received from the server was
>> 70,900,302 milliseconds ago. The last packet sent successfully to the
>> server was 70,900,302 milliseconds ago. is longer than the server configured
>> value of 'wait_timeout'. You should consider either expiring and/or testing
>> connection validity before use in your application, increasing the server
>> configured values for client timeouts, or using the Connector/J connection
>> property 'autoReconnect=true' to avoid this problem.
>> org.apache.oozie.store.StoreException: E0600: Could not get connection, The
>> last packet successfully received from the server was 70,900,302
>> milliseconds ago. The last packet sent successfully to the server was
>> 70,900,302 milliseconds ago. is longer than the server configured value of
>> 'wait_timeout'. You should consider either expiring and/or testing
>> connection validity before use in your application, increasing the server
>> configured values for client timeouts, or using the Connector/J connection
>> property 'autoReconnect=true' to avoid this problem.
>>
>> My job does a bunch of imports from SQL using sqoop and starts out like this:
>> <fork name="fork">
>> <path start="import-table1"/>
>> <path start="import-table2"/>
>> <path start="import-table3"/>
>> <path start="import-table4"/>
>> </fork>
>>
>> <action name="import-table1">
>> <sub-workflow>
>>
>> <app-path>${nameNode}/user/${wf:user()}/${appRoot}/sqoop-import-table</app-path>
>> <propagate-configuration/>
>> <configuration>
>> <property>
>> <name>tableName</name>
>> <value> table1</value>
>> </property>
>> </configuration>
>> </sub-workflow>
>> <ok to="join"/>
>> <error to="email-sqoop-failure"/>
>> </action>
>>
>> <etc…>
>>
>> Thanks.
>>
>> Ken
>
>
>
> --
> Harsh J
