feat: improve waiting for notifications by providing a timeout option #778
Conversation
…ction.getNotifications() method. The change does not have any effects for users that don't use this functionality and the API remain fully backwards compatible.
Codecov Report
@@ Coverage Diff @@
## master #778 +/- ##
============================================
+ Coverage 65.26% 65.27% +<.01%
- Complexity 3505 3519 +14
============================================
Files 165 165
Lines 15184 15219 +35
Branches 2456 2465 +9
============================================
+ Hits 9910 9934 +24
- Misses 4090 4099 +9
- Partials 1184 1186 +2Continue to review full report at Codecov.
|
| @@ -32,6 +32,20 @@ | |||
| PGNotification[] getNotifications() throws SQLException; | |||
|
|
|||
| /** | |||
| * This method returns any notifications that have been received since the last call to this | |||
| * method. Returns null if there have been no notifications. A timeout can be speficied so the | |||
|
OK, I can do that.
Von: Vladimir Sitnikov [mailto:notifications@github.com]
Gesendet: Samstag, 11. März 2017 13:39
An: pgjdbc/pgjdbc <pgjdbc@noreply.github.com>
Cc: Daniel Migowski <dmigowski@ikoffice.de>; Author <author@noreply.github.com>
Betreff: Re: [pgjdbc/pgjdbc] feat: improve waiting for notifications by providing a timeout option (#778)
@vlsi requested changes on this pull request.
Would you please add test cases to cover the new feature?
________________________________
In pgjdbc/src/main/java/org/postgresql/PGConnection.java<#778 (comment)>:
@@ -32,6 +32,20 @@
PGNotification[] getNotifications() throws SQLException;
/**
+ * This method returns any notifications that have been received since the last call to this
+ * method. Returns null if there have been no notifications. A timeout can be speficied so the
speficied -> specified
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#778 (review)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpQwwaCpSyvAMH3mZHhFDCweMJPleHxks5rkpXXgaJpZM4MaKZD>.
|
…isting unit tests. - Some JavaDoc
…n returned immediately.
|
@dmigowski any chance you can roll this #579 in at the same time ? |
|
At first I thought about to implement something like NotificationListeners also, but to implement this in a useful way there should be a Thread listening on the Socket all the time, so notifications come along truly asynchronous at the time they are sent. This thread would add incoming messages (except notifications and maybe warnings) to a queue where other Threads read them from, e.g. the QueryExecutor running statements could read its responses from that queue then.
The implementation in #579 is not very useful in my eyes because you still have to issue commands to the server or at least call getNotifications() from time to time to have the notifications delivered. If timely delivery is not a concern you can then dispatch them to your listeners manually, so nothing gained. Does anyone see a nice usecase for these notifications?
Because my first approach with having a distinct reader thread seemed to heavy, I came up with the solution of a timeouting getNotifications(), but this is of course only useful when you use your connection for nothing else but listening for notifies and reacting to them.
More thoughts: If one uses my getNotifications() with timeout on a distinct connection to the database handled by a distinct thread, one could easily write client code that dispatches these notifications.
Conclusion: When you still find the “async notification feature” useful, I would add them here, but as I said, they are not even async in the current implementation. The feature simply describes the dispatching of them on a listener basis.
Also, when one uses an addListener(PGNotificationListener, String channel)-API, we should consider if the API should issue "LISTEN <channel>" commands to the server automatically when the first listener for a channel is registered. Also we could "UNLISTEN <channel>" when the last listener has been removed. Don't know if this is useful, but then we could also provide a notify(<channel>) and a notify(<channel>,<message>)-API when we provide high level listening stuff anyway. And and listen(<channel>) function which just enables notifications that can be fetched by manually calling getNotifications().
Von: Dave Cramer [mailto:notifications@github.com]
Gesendet: Samstag, 11. März 2017 22:04
An: pgjdbc/pgjdbc <pgjdbc@noreply.github.com>
Cc: Daniel Migowski <dmigowski@ikoffice.de>; Mention <mention@noreply.github.com>
Betreff: Re: [pgjdbc/pgjdbc] feat: improve waiting for notifications by providing a timeout option (#778)
@dmigowski<https://github.com/dmigowski> any chance you can roll this #579<#579> in at the same time ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#778 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpQwwDDy8fK5m-7cN9KIcAeSKqrfzRKks5rkwxRgaJpZM4MaKZD>.
|
|
@vlsi: I added the unit tests, also fixing a bug I found in the mean time. The code coverage is sadly -0.01% now, because i added some code I cannot get to run in the tests (the case of a Warning sent by the server while waiting for notifications). I would fix that if you can tell me how to simulate that in my tests. |
|
Also would like to have my patch committed now. I could create a separate one for #579 if that is still wished for. |
|
looks good to me |
|
@dmigowski #579 is mine, he's not insulted by it ;) I'll try to get to this Monday. Thanks! |
|
Thank you very much! If this gets pulled in, I will prepare my next pull request which increases the drivers performance by a few percent points.
Von: Dave Cramer [mailto:notifications@github.com]
Gesendet: Sonntag, 19. März 2017 12:12
An: pgjdbc/pgjdbc <pgjdbc@noreply.github.com>
Cc: Daniel Migowski <dmigowski@ikoffice.de>; Mention <mention@noreply.github.com>
Betreff: Re: [pgjdbc/pgjdbc] feat: improve waiting for notifications by providing a timeout option (#778)
@dmigowski<https://github.com/dmigowski> #579<#579> is mine, he's not insulted by it ;) I'll try to get to this Monday. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#778 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADpQw8GMRThoDkPF9GJkR4tcz0ojxasqks5rnQ1kgaJpZM4MaKZD>.
|
|
@dmigowski , there is a couple of things that bothers me
|
|
Hello Vladimir,
I didn’t know that socket timeout was already used on other places, but you are right, I should read the current value and reset it, just in case it has been changed by other means than the options passed as connection parameters.
I will also split the different tests into separate methods.
Regards,
Daniel Migowski
|
…ations(timeout) - Broke unit test into multiple methods.
|
@vlsi: I broke up the test into pieces now and revert the timeout to the previous value after returing from getNotifications(). |
|
There is a failure in the replication test suite now that I didn't touch. Could someone please investigate? I don't think it is my fault. Tests run: 56, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 7.57 sec <<< FAILURE! - in org.postgresql.replication.ReplicationTestSuite testLastReceiveLSNCorrectOnView(org.postgresql.replication.LogicalReplicationStatusTest) Time elapsed: 0.063 sec <<< FAILURE! java.lang.AssertionError: Replication stream by execute forceUpdateStatus should send to view actual received position that allow monitoring lag Expected: <LSN{0/16D3390}> |
|
@vlsi: Is there still something to do? @davecramer: Can you pull this in now? |
|
Should #779 be closed? |
Improve waiting for notifications using the LISTEN/NOTIFY framework by adding an optional timeout to the PGConnection.getNotifications() method. The change does not have any effects for users that don't use this functionality and the API remain fully backwards compatible.
PS: Please squash commits when merging, the text of this pull request should give a nice commit message.