[jira] [Commented] (NIFI-5739) CaptureChangeMySQL should maintain its JDBC connection automatically
[
https://issues.apache.org/jira/browse/NIFI-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661861#comment-16661861
]
ASF GitHub Bot commented on NIFI-5739:
--
Github user asfgit closed the pull request at:
https://github.com/apache/nifi/pull/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)
[jira] [Commented] (NIFI-5739) CaptureChangeMySQL should maintain its JDBC connection automatically
[
https://issues.apache.org/jira/browse/NIFI-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
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)
[jira] [Commented] (NIFI-5739) CaptureChangeMySQL should maintain its JDBC connection automatically
[
https://issues.apache.org/jira/browse/NIFI-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661856#comment-16661856
]
ASF GitHub Bot commented on NIFI-5739:
--
Github user pvillard31 commented on the issue:
https://github.com/apache/nifi/pull/3103
+1, merging to master, thanks @ijokarumawak
> 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)
[jira] [Commented] (NIFI-5739) CaptureChangeMySQL should maintain its JDBC connection automatically
[
https://issues.apache.org/jira/browse/NIFI-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660169#comment-16660169
]
ASF GitHub Bot commented on NIFI-5739:
--
GitHub user ijokarumawak opened a pull request:
https://github.com/apache/nifi/pull/3103
NIFI-5739: Maintain CaptureChangeMySQL JDBC connection automatically
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [x] Does your PR title start with NIFI- where is the JIRA number
you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [x] Has your PR been rebased against the latest commit within the target
branch (typically master)?
- [x] Is your initial contribution a single, squashed commit?
### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file, including the main
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in
which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ijokarumawak/nifi nifi-5739
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/3103.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3103
commit 67617c174af5a5c5d99fdf80850e33f87e6d3d60
Author: Koji Kawamura
Date: 2018-10-23T06:38:24Z
NIFI-5739: Maintain CaptureChangeMySQL JDBC connection automatically
> 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
>
