This particular issue is related to IPv6 and how the "localhost" name is resolved in Windows. By default if the web service URL is not defined in the constructor of the client API, PDFreactor will use "http://localhost:9423/service/rest"" for the service URL. 

Now Windows seems to resolve localhost internally to the local loopback IPv6 address ::1 first, this seems to happen even though IPv6 is disabled. As the PDFreactor service is not listening on the IPv6 address, this will time out and Windows then seems to try the IPv4 address, eventually causing the long total conversion time.

According to some Google research we are certain that this issue is not limited to our Jetty application server (or PDFreactor itself) but also occurs when using other servers like e.g. Apache, MySQL or even IIS on "localhost". See for example:

As a workaround we would recommend to specify the service URL as "" in the PDFreactor client constructor. There should be no side effects on systems.