JDK-4916938 : RFE: Long wait (3-4') in PrinterJob.lookUpPrintServices() on a disconnected printer
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1,1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2003-09-03
  • Updated: 2005-05-31
  • Resolved: 2005-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 betaFixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description

Name: jk109818			Date: 09/03/2003


A DESCRIPTION OF THE REQUEST :
Actually calling this method works well, but ONLY if printers are connected on the LAN... When disconnected, the program hangs for at least 3' before returning the PrinterJob.

The PrinterJob.lookUpPrintServices() call has the same problem, leading to the same symptoms.

I suggest:

    a) to create a new method, returning true if there is an active LAN connection.
or  b) to enhance the PrinterJob.lookUpPrintServices() method, avoiding LAN scan when it isn't connected.


JUSTIFICATION :
I know print services can take time over the LAN when requesting flavors, but on the opposite side, a simple method could inform the client program when no LAN connection is available, thus permitting to avoid the long wait for the PrinterJob.
 


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Typical use could be - for a) above:

   // Test LAN (avoid minutes!)
   if (PrinterJob.isLanAvailable()) {
      // Find services (can take seconds!)
      PrintServices[] services = PrinterJob.lookUpPrintServices(ANY_FORMAT);
      if (services.length > 0) {
         // Use the services and print...
      }
   }

Or - for b) above:

   // Find services (avoid minutes if LAN disconnected!)
   PrintServices[] services = PrinterJob.lookUpPrintServices(ANY_FORMAT);
   // (Perhaps should it be for compatibility)
   //PrintServices[] services = PrinterJob.lookUpPrintServices(ANY_FORMAT, SHORT_SCAN); // SHORT_SCAN is boolean for LAN scan
   if (services.length > 0) {
      // Use the services and print...
   }


ACTUAL -
Takes about 15-30" on normal context (connected),
but waits 3-4' when LAN disconnected!
(see source below)

---------- BEGIN SOURCE ----------
import java.awt.print.PrinterJob;
import javax.print.PrintService;
import javax.print.PrintServiceLookup;
import java.util.Date;

public class PrintHangTest {

   public PrintHangTest() {
         logMsg("------ get PRINTER JOB ------ START");
         PrinterJob printJob = PrinterJob.getPrinterJob();
         logMsg("------ get PRINTER JOB ------ END");

         logMsg("------ get PRINT SERVICES ------ START");
         PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
// or    PrintService[] services = PrinterJob.lookupPrintServices();

         logMsg("------ get PRINT SERVICES ------ END");
         System.exit(0);
   }
   
   public static void main(String[] args) {
      new PrintHangTest();
   }
   
   private void logMsg(String msg) {
      Date d = new Date();
      System.out.println(d.toString() + " > " + msg);
   }
}


---------- END SOURCE ----------
(Incident Review ID: 201517) 
======================================================================

Comments
EVALUATION Fixed problem in lookupPrintServices, see bug 5023775. ###@###.### 2004-05-11 Changing the synopsis because I could not reproduce the getPrinterJob taking so long and besides our code does not query the printer during this call. What needs to be addressed here is the lookupPrintServices. The fix for 5023775 showed some improvement but is not sufficient. Native calls should be removed from the constructor of PrintService which is the cause of these delays. ###@###.### 2005-04-13 18:04:13 GMT
13-04-2005