@lahodaj I don't see a blocker for merging, so feel free to do so
@subhash-arabhi (or maybe @lahodaj?) I still would like to know why this construct was used:

private static final RequestProcessor RP = new RequestProcessor(NbPacScriptEvaluator.class.getName(), Runtime.getRuntime().availableProcessors(), true, false);

The common case is a thoughput of 1.

@lahodaj I don't see a blocker for merging, so feel free to do so @subhash-arabhi (or maybe @lahodaj?) I still would like to know why this construct was used:

private static final RequestProcessor RP = new RequestProcessor(NbPacScriptEvaluator.class.getName(), Runtime.getRuntime().availableProcessors(), true, false);

The common case is a thoughput of 1.

Throughput 1 is common, and sometimes needed for correctness, but here probably not. There may be multiple URL connections initialized concurrently at the same time, and for each of them the PAC script may need to be evaluated. Currently (before this PR), there will be as many PAC script evaluations as there are connections, but we need to put the PAC script evaluation to a separate thread, so that it can be cancelled. If we used throughput 1, it would mean the URL connections initialization would be (more or less) sequential.

It is not completely clear what is the ideal throughput, but I suspect it will turn out that there aren't so many concurrent URL connections initializations from the IDE, so the throughput does not matter so much. Overall, I suspect 1 might be too little. We could hardcode some other constant, but available processors does not look too bad. If the experience is bad, we can try to improve/fix.

Note the throughput does not mean the threads are assigned only for this RequestProcessor, it is only the maximum concurrent threads assigned for tasks from this RP. The threads are shared across all instances of RequestProcessor, so if they are not used by this RP, some other RP will use them.