Shared PostgreSQL database not fully syncing user inputs

[m-mauersberger]

JabRef 5.1--2020-06-30--5f2b994
on Linux 4.12.14-lp151.28.52-default amd64 (openSUSE Leap 15.1)
with Java 14.0.1

I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

When I use shared PostgreSQL database, user inputs are not synced properly. Only the first character is saved to database.

Steps to reproduce the behavior:

1. I have a shared PostgreSQL database with ~5600 entries.
2. Via GUI and keyboard, I type in entry field content (e.g. Note under Optional fields), for example '12345'.
3. Before displaying first input character, I have to wait ~7 seconds. Then, every input seems to be saved to database.
4. Reopening database reveals that only the first character '1' is actually saved to entry field Notes.

New entries are properly synced if I copy it from another database (e.g. BIBTEX).

err_log.txt
log.txt

Apparently, JabRef constantly throws java.net.SocketTimeoutExceptions. See special errors when typing inputs at log excerpt below.

Log File

javax.net.ssl|DEBUG|1E|pool-4-thread-1|2020-06-30 15:34:39.705 CEST|null:-1|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|1E|pool-4-thread-1|2020-06-30 15:34:39.706 CEST|null:-1|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|1E|pool-4-thread-1|2020-06-30 15:34:39.755 CEST|null:-1|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|1E|pool-4-thread-1|2020-06-30 15:34:39.757 CEST|null:-1|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|1E|pool-4-thread-1|2020-06-30 15:34:39.918 CEST|null:-1|duplex close of SSLSocket
javax.net.ssl|DEBUG|1E|pool-4-thread-1|2020-06-30 15:34:39.921 CEST|null:-1|close the SSL connection (passive)

[koppor]

@abepolk Can you have a look?

[abepolk]

Sure! I'm actually in the final week of a coding bootcamp (a web development training class) and working on my final project, so at this moment I don't have time to write the fix. But I took a look, and it appears similar to a problem I ran into before. I think https://github.com/JabRef/jabref/blob/master/src/main/java/org/jabref/model/database/event/CoarseChangeFilter.java was meant to address this, but I don't think I ever fixed it.

[abepolk]

#4461 (comment)

[m-mauersberger]

Thank you for caring for my problem with JabRef. May I ask if there is already a light at the end of the tunnel, i.e. the bug appears to be fixed in one of the next commits? Or is it still open?

I'm sorry for being too impatient... At the moment, solving this issue decides whether my colleagues and I can use the software at all or not.

[abepolk]

My pleasure. I am not sure it is fixed - I do not remember fixing it myself. If anyone else wants to look into this, see my comment above and the comment before the one linked to.

[m-mauersberger]

I had a look at the concerning File CoarseChangeFilter.java and have a question about:
At which exact instant FieldChangeEvents are fired? Is there an event for every single text input or for every 'completed' field? In the latter case, maybe it would be better to link the Filter to this event of completion. Does FieldChangedEvent depend directly on the GUI input or indirectly on some special GUI events (like getting text focus etc.)? In the first case, does the delta > 1 make sense?

Thank you for kindly regarding my ideas. Maybe you can use them for a fix?

[koppor]

Doesn't the JavaDoc indicate something? We kindly invite you to investigate further. All core developers are occupied by other tasks (more than the visible 306 isses). In case you don't have time, we have to hope that someone dives into here (or that enough money is coming in (via donations) that we can fund a developer.

[abepolk]

I had a look at the concerning File CoarseChangeFilter.java and have a question about:
At which exact instant FieldChangeEvents are fired? Is there an event for every single text input or for every 'completed' field? In the latter case, maybe it would be better to link the Filter to this event of completion. Does FieldChangedEvent depend directly on the GUI input or indirectly on some special GUI events (like getting text focus etc.)? In the first case, does the delta > 1 make sense?

Thank you for kindly regarding my ideas. Maybe you can use them for a fix?

I'm not sure, but if I remember correctly a FieldChangeEvent is fired for each typed letter, not for submission. The purpose of CoarseChangeFilter is to allow only relevant changes to be listened to when individual keystrokes do not matter.

[m-mauersberger]

Finally, I set up IntelliJ by this documentation for testing some changes in JabRef source code.

I have tried to change CoarseChangeFilter in order to quickly find out how it would work. It seems that fieldChange.getDelta() > 1 does not achieve the filtering function assumed. Because FieldChangeEvents are fired for every typed letter, delta of fieldChange is always 1.

By omitting this condition, the database update process is only executed when a new entry is edited. Due to single-letter events this happens only when the first character has been typed - and not for all further characters.

By omitting the second condition also, database is synchronized by every letter typed (no CoarseChangeFilter). That leads to the slow responsiveness regarded in #4461.

So my idea was to introduce a new class FocusChangedEvent. Its objects are fired when a Field in the EntryEditor is getting the focus by setFocusToField. The attribute entry is used to set up a new attribute isFocusedField at BibEntry. Every time when the focused field is set by setFocusedField in a BibEntry, a new FocusChangedEvent should be fired. At the same time, the DMBSSynchronizer should listen to an additional FocusChangedEvent in order to initiate a new database synchronization.

Is that idea basically possible and reasonable to add in this way? Of course, it does not work in JabRef at the moment... Maybe I have overseen a thing or an important scope limit. You can find some files attached to reproduce.

Would it be possible for you to inspect and review my ideas? Thank you very much for your help.

200817_Issue_6663.zip

[Siedlerchr]

Thanks for your detailed analysis and your changes. It would be great if you could create a pull request with your changes. That makes it easier for us to see the changes and review the code

[abepolk]

It's been a while since I looked at this and I don't completely remember enough details to quickly respond, but thank you for picking up where I left off! I will review your code further if I have time. Feel free also to connect with me on LinkedIn and message me separately for help with Git or making a pull request if you're new.

[m-mauersberger]

Thank you for your hints and help offering!
I made a pull request #6771 with which maybe we can find a solution.

At the moment, the changes does not work as intended... Do you have an idea?

[tobiasdiez]

Thanks to you :-) this should be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks! Please remember to make a backup of your library before trying-out this version.