[ https://issues.apache.org/jira/browse/NIFI-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661859#comment-16661859 ]
ASF subversion and git services commented on NIFI-5739: ------------------------------------------------------- Commit d28b1172db974cb1bd6aeba479b7655ce89c42db in nifi's branch refs/heads/master from [~ijokarumawak] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d28b117 ] NIFI-5739: Maintain CaptureChangeMySQL JDBC connection automatically Signed-off-by: Pierre Villard <pierre.villard...@gmail.com> This closes #3103. > CaptureChangeMySQL should maintain its JDBC connection automatically > -------------------------------------------------------------------- > > Key: NIFI-5739 > URL: https://issues.apache.org/jira/browse/NIFI-5739 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions > Affects Versions: 1.2.0 > Reporter: Koji Kawamura > Assignee: Koji Kawamura > Priority: Major > > CaptureChangeMySQL uses two different connections to the target MySQL server. > A) binlog client, B) JDBC client. The JDBC client is used to query table > column definition, which is not returned by binlog messages. > CaptureChangeMySQL establishes the JDBC connection when it starts. If the > connection is not used for the next configured wait_timeout period (defaults > to 28800 secs), the connection will be thought as an idle connection and > closed by MySQL server. That happens if no new table gets created, and no DML > is executed for the new table. The binlog client can stay connected in this > situation. > After the connection got closed, if a DML event is received, and if its table > column info is not known yet, then CaptureChangeMySQL will get the table > column info by executing a query using the connection. As a result, following > error occurs: > {code:java} > org.apache.nifi.processor.exception.ProcessException: java.io.IOException: > The last packet successfully received from the server was 55,237 milliseconds > ago. The last packet sent successfully to the server was 55,238 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. > at > org.apache.nifi.cdc.mysql.processors.CaptureChangeMySQL.onTrigger(CaptureChangeMySQL.java:593) > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1165) > at > org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:203) > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.io.IOException: The last packet successfully received from > the server was 55,237 milliseconds ago. The last packet sent successfully to > the server was 55,238 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. > at > org.apache.nifi.cdc.mysql.processors.CaptureChangeMySQL.outputEvents(CaptureChangeMySQL.java:772) > at > org.apache.nifi.cdc.mysql.processors.CaptureChangeMySQL.onTrigger(CaptureChangeMySQL.java:571) > ... 10 common frames omitted > {code} > CaptureChangeMySQL should maintain underlying JDBC connection automatically, > so that the processor can keep running. -- This message was sent by Atlassian JIRA (v7.6.3#76005)