Stop UI from locking when running thread

[tom davies]

I have a GUI with a file upload section which reads, parses and stores into a database the data within.
I have the parser separate to my user interface, it worked fairly quick on my computer but testing it on others it was painfully slow. I decided to multithread it in an attempt to speed the process up. My parser now implements runnable and i create a fixed thread pool in my GUI and feed the runnables to the threads. On my machine i can process the 153 files in less than a second but again on other computers it takes 30, 40 seconds + depending on how big i set the thread pool to.
The main problem is that when the files are being processed it locks my GUI so i cant click on anything during that time. It didn't seem a problem on my machine as there isn't a lot i can do in a second but when the process lasts up to a minute on other machines i have a problem.

Here is the code which creates the threadpool and executes the runnables, this is within my actionlistener for the upload button.
So any help on how to stop it locking my GUI and also how i can speed up the process on other machines would be great

if(!folderLocation.getText().equals(""))
                {
                    String location = folderLocation.getText();
                    File directory = new File(location);
                    File[] allfiles = directory.listFiles();
                    
                    //Thread pool with fixed size
                    ExecutorService threadPool = Executors.newFixedThreadPool(15);
                    
                    String files;
                    for(int i = 0; i<allfiles.length; i++)
                    {
                        if (allfiles[i].isFile()) 
                        {
                            files = allfiles[i].getName();
                            if (files.endsWith(".txt") || files.endsWith(".TXT"))
                            {
                                System.out.println(files);
                                //Parser is a runnable
                                databaseLog adatabaseLog = new databaseLog(location + "/" +files);
                                //Execute the runnable
                                threadPool.execute(adatabaseLog);
                            }
                        }
                    }

[Manuel Petermann]

What does Gui mean? Swing, JavaFx, SWT or something else?

Secondly you databaseLog class violates the java naming convention. You should use an uppercase letter up front.

You might want to delegate the whole thing to a SwingWorker (Swing), Task/Service (JavaFx) or something similar for your Framework.

This is because right now you highly depend on the files being on a fast filesystem and that there are not that many files. If that is not the case, maybe because of a network filesystem or simply a very slow/ already busy filesystem, you are stuck with an unresponsive gui.

[tom davies]

Manuel Petermann wrote:What does Gui mean? Swing, JavaFx, SWT or something else?

Secondly you databaseLog class violates the java naming convention. You should use an uppercase letter up front.

You might want to delegate the whole thing to a SwingWorker (Swing), Task/Service (JavaFx) or something similar for your Framework.

This is because right now you highly depend on the files being on a fast filesystem and that there are not that many files. If that is not the case, maybe because of a network filesystem or simply a very slow/ already busy filesystem, you are stuck with an unresponsive gui.

Sorry i am using Swing for the user interface.
I have never used SwingWorker before, would i use it in a similar way to threads? databaseLog would extend SwingWorker and then i use the doInBackground() method instead of run?

[Manuel Petermann]

For starters yes.
Anyway, You wouldn't solve your initial problem that way.
If your databaseLog would simply extend SwingWorker you would end up creating exactly as many new workers as there are files.
That is a bad idea for your problem because as far as i know most filesystems cannot read more than one file at a single point in time anyways.
The fact that a SwingWorker is limited to 10 distinct threads is just a sidenote to that.
Ps:
Think about what you also might want to do in a separate thread.
Pps:
Oh You just need 1 thread/SwingWorker for that.

[tom davies]

Manuel Petermann wrote:For starters yes.
Anyway, You wouldn't solve your initial problem that way.
If your databaseLog would simply extend SwingWorker you would end up creating exactly as many new workers as there are files.
That is a bad idea for your problem because as far as i know most filesystems cannot read more than one file at a single point in time anyways.
The fact that a SwingWorker is limited to 10 distinct threads is just a sidenote to that.
Ps:
Think about what you also might want to do in a separate thread.
Pps:
Oh You just need 1 thread/SwingWorker for that.

Would i just have one SwingWorker which handles what ive already got displayed above, so the SwingWorker would select the files and then call the databaseLog etc.

[Manuel Petermann]

I would split it up in something more abstract but your solution would work too.

[tom davies]

It appears the problem is solved now. I just created another thread and put everything you see there into that thread as it was the actual reading of the files causing it to lock.
Also the variation in performance was mainly down to the fact the files on the other computers i tested were being accessed through a network and not local to those machines. It now processes to quick on my machine to test it properly but being very quick i can access other parts of the GUI which i couldnt before. I will do some more testing on other machines but i think it is resolved now.