Skip to Main Content

Java SE (Java Platform, Standard Edition)

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

How to Filter JTable Rows as Data Changes

871939Jun 28 2011 — edited Jun 29 2011
Hello,

any helpful suggestions are welcome, I'm at a bit of a dead end at the moment.

So I have a JTable backed by a table model. The data in the table is liable to change while the system is running, when it does some events are raised. The table model listens for the appropriate events so that it can work out which row in the table needs to be updated, I can then call through to
int row = determineWhichRow( changedDataObject );
fireTableRowsUpdated( row, row );
This correctly causes the table row to update. Now the bit thats going wrong. The user is able to enable filters on the table, specifically on an attribute of the data in this table that changes. So when I fire the update event I need my row sorter (with the filters set) to re-sort the table. Having a look around there is a method on row sorter:
getSortsOnUpdate()
which from the javadoc I believed would create the behaviour I needed - assuming I told it to return true. Having tried this the functionality remains the same, as the data model changes, the values in the table update but the filters are not reapplied.

Debugging through the jdk code to get an idea of what might be going on it seems that the filters are called and it determines that the changed row should be filtered out, but gets to a point where it decides that because the event from the table model was an update event it shouldn't call a resize and repaint method and nothing further seems to happen.

I believe that simply re-setting the row sorter on the table would cause the desired effect but would be incredibly inefficient with a data model that can potentially change at any time. I can post the specific line numbers and jdk version if that is going to help anyone, but hopefully you'll all be able to give me an idea of what I might have missed.

Thanks,

Dan.
This post has been answered by jduprez on Jun 29 2011
Jump to Answer

Comments

If you shutdown mysqld, are the files freed?

3412947
Answer

I am experiencing the same problem and spent the majority of my work day yesterday researching it.  I believe you are hitting a known bug that affected MySQL 5.7.22 - 5.7.25 and 8.0.14 - 8.0.15.  It has been fixed in 5.7.26 and 8.0.16.  Oracle BUG id is 28039829 "File handles are leaked for SELECT queries involving complex joins."  The way MySQL uses on-disk internal temp tables (those produced during a query, not the explicit temporary tables that a user can create), to not leave any temp files behind in case of a server crash, by design MySQL creates the tmp file, and then immediately unlinks it (so it appears to the OS as deleted), but MySQL keeps the descriptor open to the file. You can see this under /proc/{mysqld pid}/fd.  When these work normally, once the thread is done with the temp table, it releases the descriptor and the space and open file are released.   But due to a mistake in file handles that was introduced, it was possible that the descriptors were not being freed.  If you upgrade to the latest release, the problem should go away.  In the meantime, you can workaround (sort of), by setting your max open files higher and giving your tmp location some extra space, and even then you may have to periodically bounce mysqld to reclaim the fds and space.  The bug report has a partial workaround on 8.0.14 & 8.0.15 suggested to set loose_internal_tmp_mem_storage_engine=MEMORY.  For my servers, I run the Percona Server fork, and they have not released their 8.0.16 port (yet as of today), and I eagerly await it.

Marked as Answer by 3837224 · Sep 27 2020
3837224

Yes, I confirm that with upgrade to 8.0.16 the bug has been fixed.

Andy_C

We're having the same problem (8.0.15) - it's a show stopper for us but we have a very extended upgrade time-line so we need a work-around (or work-arounds) that will keep this from occurring until we're able to upgrade (to 8.0.17).

One obvious work-around is to stop and restart mysqld (say weekly) - however, that's kind-of a big deal timing-wise and the problem could still occur between restarts.

In terms of the broken sym-links - does anybody know if it's safe to remove them? That would be an easy, safe, and reliable work-around. I'm thinking that since the files are no longer needed (they were temp files) and are no longer on disk and mysql was supposed to have removed the sym-links anyway it would be ok to run a script periodically to remove them. However, I don't know if mysql would 'object' to them being removed by a non-mysqld process.

Thank you!

Andy

1 - 4
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jul 27 2011
Added on Jun 28 2011
8 comments
8,098 views