I presume that your method openFile() method is being called from the event dispatching
thread, ie. from some button handler code.
All events are handled by the event dispatching thread, including instructions to repaint the form. What has essentially happened is that by opening a large file for processing you have
hijacked that thread. Repaints which would have been queued to redraw that missing part of the form once it closed are not being actions because your processFile(...) method is being run in the event thread.
What you are descriving is not really a producer/consumer scenario. When performing costly long operations it is nearly always a good idea to spawn a worker thread, do the work in that thread and then use a mechanism to invoke across threads to cause the GUI to be updated.
SwingWorkerThread, which is not part of the standard SwingAPI is a nice little class that can help you out in such cases. You can find out all about it at
this page which details how to use the SwingWorkerThread or here from the
Swing Tutorial.
Essentially it is a subclass of java.lang.Thread that allows you to detail your long running operation in a method called construct(), which will be run in its own thread, and then, when the thread runs to completion code that is provided in the method finished() is run from the event dispatching thread (using a call such as SwingUtilities.invokeLater(...)).
Code which updates GUI state should always be called from the event dispatching thread, this is a central tennant of Swing (and most other UI toolkits) and using the SwingWorkerThread makes this simple for you.