# Does jdbc\_user get signed out after run of pipeline?

**URL:** <https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407>\
**Category:** Logstash\
**Tags:** jdbc\
**Created:** [June 16, 2022, 12:55pm UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407 "2022-06-16T12:55:55Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![DazDotOne](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dazdotone/32/102049_2.png) [@DazDotOne](https://discuss.elastic.co/u/DazDotOne)\
**Post date:** [June 16, 2022, 12:55pm UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/1 "2022-06-16T12:55:55Z")

</div>

Sorry if this is answered elsewhere, I had a look around the web but couldn't really find anything.

After a pipeline has executed, does this plugin sign the given user out from the SQL server or retain the connection for future runs?

If the latter, is there a way to force a sign out to happen?

I'm connecting to an annoying proprietary flavour of SQL which has some steep licencing costs and currently getting an error which suggests that the user connections from my dev/test/staging environments are still signed in.

I was just trying to gather some data before I approach the service provider (as their support is pretty rough, and you guys rule!).

Thanks

---

<div class="post-metadata">

**Author:** ![DazDotOne](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dazdotone/32/102049_2.png) [@DazDotOne](https://discuss.elastic.co/u/DazDotOne)\
**Post date:** [June 28, 2022, 9:56am UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/2 "2022-06-28T09:56:26Z")

</div>

OK so I've been doing some digging.

By running `netstat -an` I've found that my standard SQL server connections all show as `established` and the ones to the proprietary SQL mentioned in the original post are showing as `close_wait`.

This seems to suggest that logstash doesn't close the connection correctly after querying. At least by default.

Is there something I'm missing?

Also, is there anybody here? There doesn't seem to be any docs around this and the plugin page says to ask questions here. If I'm missing any helpful info please ask and I'll supply it.

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [June 28, 2022, 4:24pm UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/3 "2022-06-28T16:24:41Z")

</div>

Assuming the plugin you are using uses the [mixin](https://github.com/logstash-plugins/logstash-input-jdbc/blob/878a73eb67b68366fac74fcc65e9cadd6cf44766/lib/logstash/plugin_mixins/jdbc/jdbc.rb#L240), the connection is opened before a statement executes and closed after. On the other hand, the [integration](https://github.com/logstash-plugins/logstash-integration-jdbc/blob/607a5b587c668a3792811cd4f005afefacf53774/lib/logstash/inputs/jdbc.rb#L241) uses long-lived connections. So the answer is going to depend on which version of which plugin you are asking about.

---

<div class="post-metadata">

**Author:** ![DazDotOne](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dazdotone/32/102049_2.png) [@DazDotOne](https://discuss.elastic.co/u/DazDotOne)\
**Post date:** [June 29, 2022, 8:29am UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/4 "2022-06-29T08:29:38Z")

</div>

Hey Badger,

Thanks so much or the response. I'm currently trying to nail down whether it's the plugin or the driver I'm having to use so this is super helpful.

Ok so the following is the output from Logstash CLI:

```auto
# logstash --version
logstash 7.16.2

# logstash-plugin list --verbose
logstash-integration-jdbc (5.1.8)
 ├── logstash-input-jdbc
 ├── logstash-filter-jdbc_streaming
 └── logstash-filter-jdbc_static

```

I'm using it with docker and the version of LS I'm using is unfortunately limited by the version of elastic we're using in production.

I haven't really done anything with the version of the plugin, that's the one that comes packaged with the the image `docker.elastic.co/logstash/logstash:7.16.2` but looking at the [plugin page](https://www.elastic.co/guide/en/logstash/7.16/plugins-inputs-jdbc.html), this is the correct version for this version of LS.

It looks like the suggested mixin was merged in `4.3.19` so I'd assume that it would be using it. What would be the best way to verify?

Thanks again.

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [June 29, 2022, 4:26pm UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/5 "2022-06-29T16:26:12Z")

</div>

> [@DazDotOne](#):
>
> What would be the best way to verify?

You would have to wade through the github change logs, but it certainly looks like you are using the integration.

---

<div class="post-metadata">

**Author:** ![DazDotOne](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dazdotone/32/102049_2.png) [@DazDotOne](https://discuss.elastic.co/u/DazDotOne)\
**Post date:** [July 1, 2022, 2:18pm UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/6 "2022-07-01T14:18:32Z")

</div>

Awesome, Thanks again for your help Badger.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 29, 2022, 2:18pm UTC](https://discuss.elastic.co/t/does-jdbc-user-get-signed-out-after-run-of-pipeline/307407/7 "2022-07-29T14:18:55Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
