vsilaev / tascalate-concurrent Goto Github PK

The problem is in the following code:

// exceptions are handled in regular way
failure -> {
    try {
        action.accept(null, failure);
        return forwardException(failure);
    } catch (Throwable e) {
        // CompletableFuture does not override exception here
        // unlike as in handle[Async](BiFunction)
        // Preserve this behavior, but let us add at least 
        // suppressed exception
        failure.addSuppressed(e);
        return forwardException(failure);
    }
}

The forwardException throws a CompletionException which is immediatelly caught by the catch clause. Then, it is added to the failure as a suppressed exception. However, it can happen that failure == e (is the same object) since failure is retrown when its type already is the CompletionException.

I added a test for this in #8.

What about calling the forwardException after the try-catch block as in the following code? This also make the code a little bit cleaner since there is only one call to forward... now :)

// exceptions are handled in regular way
failure -> {
   try {
       action.accept(null, failure);
   } catch (Throwable e) {
       // CompletableFuture does not override exception here
       // unlike as in handle[Async](BiFunction)
       // Preserve this behavior, but let us add at least 
       // suppressed exception
       failure.addSuppressed(e);
   }
   return forwardException(failure);
}

Hi,

First of all, thank you for your code, it helped me really a lot as I needed in my GUI the ability to cancel the running underlying task. Moreover, your code enables me to extend this cancellation ability such that I could cancel the whole tree of underlying tasks which the "root" task depends on. This extension is currently in progress, and when finished I would like to share it with you. Would you be interested?

Anyway, I think I found an issue in the original code today. I wrote a simple test (OnSuccessTest) which runs two async tasks, the first one and then the second one. In the test I cancel the first task but the second one still can be executed which it should not as the first stage should complete exceptionally with CancellationException. For me the issue occurs when the first task is cancelled (from main thread) using AbstractCompletableTask.cancel(true) but the onError(...) in this method is DELAYed (I added some code before). In this case the StageTransition.set(...) method can be executed from FutureTask.run() during the DELAY on a thread pool thread and the first stage is completed successfully despite of its task was cancelled.
My solution is to test the completion status of the task in StageTransition.set(...) and call either onError(...) when the task was cancelled or onSuccess(...) otherwise.

test.zip

Hi Valery,

this simple test case breaks here with the latest release:

    @Test
    public void test_orTimeout_does_not_break_cancellation_ability() {
        State s1 = new State();
        Promise<Void> p = CompletableTask.runAsync(() -> longTask(5, s1), executor)
                .orTimeout(2, TimeUnit.SECONDS);
        trySleep(2);
        p.cancel(true);
        trySleep(1);
        assertCancelled("s1", s1);
    }

Took me a couple of hours to figure out that orTimeout() causes it. Other than that, I think that your library is great to overcome the cumbersomeness of the original implementation. Thanks!

PS: I guess increasing the overall unit test coverage would also help your development as the stuff is pretty complex and multithreading done right is very hard.

A minor issue but... The docs are quite good but there are several places in the documentation where a method is highlighted. For example:

Second, there is an adapter method from:
static Promise from(CompletionStage stage)

It is not immediately clear in which class this method is located. The reader has to scan the surrounding text and spot the sentence:

When discussing Promise interface, it's mandatory to mention the accompanying class Promises

to realize this method is located in Promises.

An easy way to fix this might be to simply include a class name when highlighting a method in the documentation. The best way to fix this would be for method highlights to actually link to javadoc. This way when the user remembers that a method exists but is unsure which class the method is located in she can quickly search the docs and then click through to the javadoc.

In this example:

   State s1 = new State("s1");
   State s2 = new State("s2");

    DependentPromise<String> promise = DependentPromise.from(
            CompletableTask.asyncOn(executorService)
    ).thenApplyAsync(
            (aVoid) -> longTask(...), true
    ).thenApplyAsync(
            (s) -> longTask(...), true
    ).exceptionally(
            (e) -> {
                System.out.println(e.getMessage());
                return null;
            }, true
    );

If I call promise.cancel() and lets say that longTask will throw a RuntimeException when it gets interrupted. Should exceptionally() get called since the task did not complete successfully?

I like twitter Futures model where I can cancel the future I receive AND it cancels ALL futures in the chain UNLESS someone broke the chain by nulling out the cancel handler. This is really nice as it cancels the future you are waiting on AND any other futures that may be outstanding so those lambas will not run since I cancelled the entire request. This would reclaim all the processing on the cancel unlike java futures which only cancel the first future.

SO post was closed but is here
https://stackoverflow.com/questions/62106428/is-there-a-better-way-for-cancelling-a-chain-of-futures-in-java?noredirect=1#comment109864875_62106428

closed because the above I guess is an opinion.

Dean

Hi Valery,

I would like to have the method Promises.failure typed using a type parameter. This would make returning a failed promise easier in cases when the async task was not even started.

The method would look like:

public static <T> Promise<T> failure(Throwable t) {
    @SuppressWarnings("unchecked")
    CompletablePromise<T> result = (CompletablePromise<T>) new CompletablePromise<Object>();
    result.onFailure(exception);
    return result;
}

This is inspired by the implementation of Collections.emptyList().

Currently, I am using a workaround. I create a failure and I link another stage after it using thenApply which allows me to return the desired type.

Regarding Promises.all there is a problem with its parameter type. If you would like to specify the aggregated Promises differently then by listing them, you need to supply an array of a generic type (a Promise). In Java you cannot create such arrays directly. First you need to create a collection and then convert it to the array while you need to do an unchecked cast. It would be more convenient to provide also a method which works with collections.

Anyway, thank you for your great library.
Best, Adam

Is there a way to make it so that if you have a Promise, you have a method like

Promise.thenRunSwitch(Runnable run, Executor toDo)

where the following holds true:

1. If parent promise executed on executor toDo, delegate to method thenRun
2. If parent promise executed on another executor, delegate to method thenRunAsync with executor toDo

That way, there is minimized context switching and if you are already running under a thread you want to be in, you can stay on that thread.

I'd like to open a discussing regarding design choice I made for Promise.orTimeout and Promise.completeOnTimeout.

Promise.orTimeout returns a new Promise that is either completed normally when original Promise completes normally within timeout given, or completes exceptionally, when original Promise completes exceptionally within timeout given, or completes exceptionally with TimeoutException if timeout was exceeded.

When the returned Promise is cancelled, timeout is cancelled as well. However, original Promise is not cancelled and its completion code keeps running. Moreover, if timeout happens then original Promise is not cancelled either.

Why? To support different execution paths depending on timeout duration. For example:

Promise<String> serviceCall = someSlowServiceCall();

serviceCall.orTimeout(Duration.of(5, ChronoUnit.SECONDS)).exceptionally(e -> {
  if (e instanceof TimeoutException) {
    UI.showMessage("Sorry, it takes a bit longer than expected. Please wait...");
  }
});

serviceCall.onTimeout(Duration.of(20, ChronoUnit.SECONDS)).exceptionally(e -> {
  if (e instanceof TimeoutException) {
    if ("Y".equals(UI.showConfirmation("Server does not respond, do you want to cancel operation (Y/N)?"))) {
      serviceCall.cancel();
    }
  }
});

Obviously, there is a way to cancel original promise as well with minimal coding:

Promise<String> serviceCall = someSlowServiceCall();
Promise<String> withCancelOnTimeout =
  serviceCall
  .orTimeout(Duration.of(5, ChronoUnit.SECONDS), true)
  .exceptionally(e -> serviceCall.cancel(true));

Promise.completeOnTimeout is almost identical in behavior, the only difference is that in case of timeout the returned promise is completed with alternative value (supplied as argument).

Both orTimeout and completeOnTimeout are executed on the default executor of the original Promise.

What do you think?

The documentation about Promises#all(CompletionStage<? extends T>...) suggests that canceling a Promise that has been created using Promises#all cancels all Promisses that are wrapped inside. That does not seem to work. Please have a look into
CompletableTaskCancellationTest.java.txt methods testWrappedCancel*. (Executors#getDefaultExecutor() returns
new ThreadPoolTaskExecutor(10, 20, 30, TimeUnit.SECONDS, new LinkedBlockingQueue<>(30))).

Hi Valery,

I hope you are doing well.
I just tried to create an all promise from a list of promises. See the follwing code:

List<Promise<T>> promises = new ArrayList<>();
Promise<?> all = Promises.all(promises);

And this does not compile since the generic type of the promises argument is too narrow. Specifically, we would need it to be Promise<T> all(List<? extends CompletionStage<? extends T>> promises). Maybe Promise<T> all(Collection<? extends CompletionStage<? extends T>> promises) could also work.

Best, Adam

MultitargetException swallows underlying Exceptions making it absolutely impossible to determine what the original, underlying exception was. The MultitargetException constructor takes a list of Exceptions and makes no attempt to initCause() and set any of the exceptions in the list as a cause of the MultitargetException. When a MultitargetException occurs it is impossible to what caused the MultitargetException.

The MultitargetException constructor should change. Specifically:

1. If the list is an empty an IllegalArgumentException should be thrown.
2. The constructor should take the first element of the list and invoke initCause() with the first element as a parameter.

This should make it possible to always be able to determine what caused a MultitargetException.

Additionally the MultitargetException should override Throwable.getMessage(). When an exception occurs we really need as much information as possible as to why the exception occurred. Ideally MultitargetException.getMessage() would print out the number of exceptions and then print out detailed information about each exception occurred. Minimally we need to see the getMessage() for each of the Exceptions in the list.

MultitargetException maintains its own list of throwables. Instead MultitargetException should use the standard SuppressedException mechanism. If there is more than one exception in the list than all remaining exceptions (except the first which is passed to initCause()) should be passed to addSupressed.

The current version of MultitargetException which doesn't use initCause and doesn't use addSupressed is a big problem. Exceptions occur in our background threadpools and in the curent design it is impossible to determine what those exceptions were without writing custom code to "unwrap" the exception. This makes the library very difficult to use.

I am using Java 8 and this library looks perfect for my case; it offers timeout feature and cancel the long running thread without upgrading to Java 9 or 11.

I am trying the onTimeout method but it seems not working as the README stated. The original Promise is not cancelled and the logic continues to run and return even after the timeout. My code is as follows.

List<CompletableFuture<ResponseEntity<String>>> futures = getFutures();
System.out.println("futures size:" + futures.size());
CompletableFuture.allOf(futures.toArray(new CompletableFuture[futures.size()])).join();
System.out.println("all futures completed");

private getFutures() {
    List<CompletableFuture<ResponseEntity<String>>> futures = new ArrayList();
    futures.add(get(proxy, "https://normal1.com"));        // returns within 5s
    futures.add(get(proxy, "https://normal2.com"));        // returns within 5s
    futures.add(get(proxy, "https://longrunning.com"));    // returns after a min
    return futures;
}

private CompletableFuture<ResponseEntity<String>> get(ProxyExchange<String> proxy, String url) throws InterruptedException {
    return CompletableTask
            .supplyAsync(() -> {
                System.out.println("inside supplyAsync(), calling foo() with url " + url);
                return foo(proxy, url);
            }, Executors.newFixedThreadPool(10))
            .onTimeout(() -> {
                System.out.println("timeout with url " + url);
                return defaultResponse();
            }, Duration.ofSeconds(30), true)
            .toCompletableFuture();
}

private ResponseEntity<String> foo(ProxyExchange<String> proxy, String url) {
    System.out.println("inside foo");
    System.out.println("calling " + url);
    ResponseEntity<String> result = proxy.uri(url).get();
    System.out.println("called " + url);
    if (CommonUtils.isNotEmpty(result.getBody())) {
        System.out.println("result not empty, with length " + result.getBody().length() );
    } else {
        System.out.println("result is empty");
    }
    return result;
}

private ResponseEntity<String> defaultResponse() {
    return ResponseEntity.ok("Timeout!!!");
}

I convert Promise into CompletableFuture after onTimeout to minimize code change as I used CompletableFuture before. It can be changed this caused the issue.

However when I check the logs,

inside supplyAsync(), calling foo() with url https://normal1.com
inside foo
calling https://normal1.com
inside supplyAsync(), calling foo() with url https://normal2.com
inside foo
calling https://normal2.com
inside supplyAsync(), calling foo() with url https://longrunning.com
inside foo
calling https://longrunning.com
futures size:3
called https://normal1.com
result not empty, with length 4301
called https://normal2.com
result not empty, with length 43695
timeout with url https://longrunning.com
all futures completed

Looking good. The page loads after 30s and it timeouts longrunning.com which I can get the defaultResponse() back. But after another 30s, following logs got printed.

called https://longrunning.com
result not empty, with length 188

I thought the onTimeout should interrupt and cancel the timeout thread. Can you point me out if I did anything wrong?

Hi,

is there a way to wait for the CompletableTask (the Promise) to be Interrupted?

For example:

Promise<Void> task = CompletableTask.runAsync(() -> {
	try{
		//...
	} catch (InterruptedException e) {
		Thread.currentThread().interrupt();
		throw new CompletionException(e);
	}
}, EXECUTOR);
task.cancel(true);
//wait for interruption

immediately after task.cancel() (eiter trueor false) task.isDone() will be true and task.join() will throw CancellationException
how can I wait for the Runnable to actually finish or interrupt?
If i call task.cancel(true); I'd like to wait untill the Runnable get interrupted (and throws new CompletionException(e); in the example).
If i call task.cancel(false); I'd like to wait for the runnable to finish if already running (or get CancellationException if not started yet)
It might be also usefull to be able to get the result or the exception after it finish or interrupt.

The ratio behind this is that if i schedule several IO bound tasks (in a FixedThreadPool), at some point i might want to cancel them, but wait for the running ones to finish or gracefully interrupt.

Hi!

I stumbled upon your library and it looks very promising! Thanks for the hard work you put into it.
While testing timeouts and cancellations, the behavior I am seeing is not what I would expect though. Here's an example:

public void test() {
     return CompletableTask
        .supplyAsync(() -> {
            try {
                Thread.sleep(10_000); // sleep 10s
            } catch (InterruptedException e) {
                System.out.println("Interrupted");
                throw new CompletionException(e);
            }
            System.out.println("Interrupted? " + (Thread.currentThread().isInterrupted() ? "yes" : "no"));
            return "foo";
        }, Executors.newCachedThreadPool())
        .orTimeout(Duration.ofMillis(200), true)
        .join();
}

With such a code, I would expect the Thread.sleep() to be interrupted after 200ms but it does not seem to be the case ("Interrupted: no" is printed after 10s). Is that the expected behavior? Am I doing something wrong?

Also, I noticed that different executors will provide different results. Using newCachedThreadPool() will return a result after 200ms while using newSingleThreadExecutor() or Spring's ThreadPoolTaskExecutor will return but only after 10s. Again, is that expected?

Thanks!

I have a computing intensive task that should stop when a certain time has expired. I'm using the onTimeout method for this but the task is not interrupted. When i add a thread sleep in the computation task the task is properly interrupted.

I'm using a ThreadPoolExecutor as executer.

Any idea what could be the cause of this?

Hi, I've been using this library for a while and recently dug out some project from over a year ago and upgraded from 0.8.4 to 0.9.6. The behaviour for onTimeout is no longer doing what it used to and I'm confused if I'm doing it wrong. The simplest test case I can see is this:

    @Test
    public void test()
    throws ExecutionException, InterruptedException
    {
        String message = "test";
        CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
            try {
                Thread.sleep(500);
            } catch (Exception e) {
                e.printStackTrace();
            }
            return message;
        });

        Promise<String> promise1 = Promises.from(future).orTimeout(Duration.ofSeconds(1));

        assertEquals(message, promise1.get());
    }

The promise1.get() reports a failure due to a CancellationException immediately. The code works and succeeds in 0.8.4. Any suggestions?

When I execute this code:

CompletableTask
  .submit(this::doTask, executor)
  .orTimeout(Duration.ofSeconds(5L))
  .whenComplete((res, err) -> {
    if (res != null)
	System.out.println(res);
    else
        System.out.println(err.getMessage());
});

private String doTask () throws Exception {
  TimeUnit.SECONDS.sleep(3);
  if (true)
    throw new Exception("my error");
  return "executed ok";
}

I never get "my error" exception after 3 secs, only TimeoutException after 5 secs with "Timeout after PT5S" message.
If I remove orTimeout(...) line, I get "my error" exception.
Is there any way to catch both exceptions?

Thanks

I am using the jersey rx() extension that wraps the requests in CompletionStages. I would like to be able to take this CompletionStage, convert it to a Promise, and use it within a Promises.retry without having to call get().

This means that Promises.retry would accept a Promise, rather than a Callable or Runnable, and then be able to resubmit the original code with binding context for re-execution.

thenCompose() and derivates are broken when it comes to Exception handling.

This code will never terminate:

    @Test
    public void test_exception_handling_with_thenCompose() throws ExecutionException, InterruptedException {
        State s1 = new State();
        Promise<Void> p = CompletableTask.runAsync(() -> longTask(1, s1), executor)
                .thenCompose(it -> {
                    throw new IllegalStateException("oh no!");
                });
        p.get();
    }

This code with the CompleteableFuture does:

    @Test
    public void test_exception_handling_with_thenCompose2() throws ExecutionException, InterruptedException {
        State s1 = new State();
        Future<Void> p = CompletableFuture.runAsync(() -> longTask(1, s1), executor)
                .thenCompose(it -> {
                    throw new IllegalStateException("oh no!");
                });
        p.get();
    }

Twitter Futures allow swapping the slf4j MDC to use Local.scala which is a special context using a combination of ThreadLocal and swapping in/out context for thenCompose and thenApply. In this way, when a request comes in, I can MDC.put("userName", userName); and it will be available to all logging across all thenApply and thenCompose methods. Without this, logging in slf4j with MDC generally breaks down. With this fix, one can swap the MDC with a FutureLocal.java usage. Of course, the Futures will have to know about FutureLocal.java to make this happen.

There's a called method name typo in the winMinDelay(mindelay, timeUnit) method of the DelayPolicy interface:

    default DelayPolicy<T> withMinDelay(long minDelay, TimeUnit timeUnit) {
        return withMaxDelay(Timeouts.toDuration(minDelay, timeUnit));
    }

Apparently it should call withMinDelay(duration).

Hi there,

me again. I have some issues with the callback mechanism used internally in tascalate-concurrent to add the successCallback etc.
The problems are due to the callbacks being added as another task execution via execute() on the Executor used.

I have identified two issues:

• If I shutdown() the executor, the remaining callback hooks will cause rejections on CallbackRegistry:291 executor.execute() and throw these exceptions all the way up, once a (previously executing) Promise completes.
• The extra task will cause starvation on SingleThreadExecutors. E.g. if I add several (hundreds) promises to the executor at once, the first promise will not terminate becauses the callback hook is only executed AFTER all other queued promises have been ALSO executed, due to in-order-execution.

Do you have any suggestions on this? Otherwise I probably have to revert to mutex/semaphores outside the executor to guarantee a single-threaded funnel, but that would defeat the purpose of the executor and might unnecessarily queue up threads waiting for the mutex to become available.

Thanks and keep up the good work
Chris

First off, great library. It's very useful for briding the gap between traditional future interrupts and the completionstage api.

However, the following caught us offguard:

• cancelling a completable task interrupts a thread
• cancelling a completable task mapped with "whenComplete" or "thenApply" does not interrupt a thread

Is this by design?

Here's a quick program to illustrate the problem:

package test;

import java.time.Duration;
import java.util.List;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.Executor;
import java.util.concurrent.Executors;
import java.util.function.BiConsumer;

import net.tascalate.concurrent.CompletableTask;

public class PromiseCancelTest {

	private static final Executor EXECUTOR = Executors.newCachedThreadPool();

	public static void main(String[] args) throws InterruptedException {
		for (var assignWhenComplete : List.of(false, true))
			run(assignWhenComplete);
	}

	private static void run(Boolean assignWhenComplete) throws InterruptedException {
		var latch = new CountDownLatch(1);
		var promise = CompletableTask.submit(() -> {
			try {
				long counter = 0;
				while (!Thread.currentThread().isInterrupted()) {
					Thread.sleep(Duration.ofSeconds(1).toMillis());
					counter++;
					log(assignWhenComplete, counter);
				}
				return counter;
			} finally {
				latch.countDown();
			}
		}, EXECUTOR);
		BiConsumer<? super Object, ? super Throwable> whenCompleteAction = (v, t) -> log(assignWhenComplete,
				"whenComplete action");
		if (assignWhenComplete)
			promise = promise.whenComplete(whenCompleteAction);
		else
			promise.whenComplete(whenCompleteAction);
		Thread.sleep(Duration.ofSeconds(4).toMillis());
		promise.cancel(true);
		log(assignWhenComplete, "cancel requested");
		latch.await();
		log(assignWhenComplete, "done");

	}

	private static void log(Boolean assignWhenComplete, Object value) {
		System.out.println(String.format("assignWhenComplete:%s %s", assignWhenComplete, value));
	}
}

When 'assignWhenComplete' is false, the thread interrupts just fine. When assignWhenComplete is false, the program runs forever:

assignWhenComplete:false 1
assignWhenComplete:false 2
assignWhenComplete:false 3
assignWhenComplete:false whenComplete action
assignWhenComplete:false cancel requested
assignWhenComplete:false done
assignWhenComplete:true 1
assignWhenComplete:true 2
assignWhenComplete:true 3
assignWhenComplete:true cancel requested
assignWhenComplete:true 4
assignWhenComplete:true 5
assignWhenComplete:true 6
assignWhenComplete:true 7
assignWhenComplete:true 8
assignWhenComplete:true 9
assignWhenComplete:true 10
assignWhenComplete:true 11
[...]

Im trying to use the library due to the fact that i must cancel stucked threads (due to stuck WMI usually)

im noticing however that despite calling the cancel or specifing short timeout with the parameter set to true, the chain continues

to make it easier to see what im doing wrong ill attach some code and logs

public Promise<ComplianceCandidate> process(ComplianceCandidate candidate, ExecutorService pool) {

        return CompletableTask.supplyAsync(() -> candidate, pool).thenApplyAsync(CheckIp::doWork)
                .thenApplyAsync(CheckType::doWork).thenApplyAsync(CheckExclusion::doWork)
                .thenApplyAsync(AssignEntity::doWork).thenApplyAsync(DecideWmi::doWork)
                .thenApplyAsync(ObtainWmiConnection::doWork).thenApplyAsync(ObtainRegistryWmiConnection::doWork)
                .thenApplyAsync(RunCompliance::doWork).thenApplyAsync(DecideComplianceResult::doWork)
                .thenApplyAsync(CreateAlert::doWork).thenApplyAsync(ApplyFailureManager::doWork)
                .thenApplyAsync(ApplyDisconnectManager::doWork).thenApplyAsync(EnforceCompliance::doWork)
                .exceptionally(ExceptionHandlerService::handle).orTimeout(Duration.ofSeconds(3), true);
    }

the timeout should affect in the task obtainWmiConnection yet im seeing the task downstream being executed (runCompliance)
im also attaching the relevant logs

2021-02-19 09:09:18 [pool-2-thread-6] - [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] has entered Decide WMI task
2021-02-19 09:09:18 [pool-2-thread-6] - [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] needs WMI connection due to condition ComplianceCondition [id=6, type=FileWMI, uniqueName=AVDatFile]
2021-02-19 09:09:18 [pool-2-thread-6] - [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] has passed Decide WMI task
2021-02-19 09:09:18 [pool-2-thread-7] - [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] has entered Obtain WMI task
2021-02-19 09:09:19 [pool-2-thread-7] - Proceeding to establish wmi connection for device: [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server]  wmiuser: localhost\administrator total users: 1
2021-02-19 09:09:23 [pool-3-thread-1] - Error TimeoutException: Timeout after PT3S on demand execution for device [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server]
2021-02-19 09:09:34 [pool-2-thread-7] - Successfully established WMI for device: [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] with WMI user: Credential [id=12, wmiDomain=localhost, wmiUser=administrator], total time to obtain connection is 15 seconds
2021-02-19 09:09:34 [pool-2-thread-10] - [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] has entered run compliance task
2021-02-19 09:09:35 [pool-2-thread-10] - [ipAddress=192.168.99.190, macAddress=0x18A905C1AAA9, type=Server] has has the system name WISE-DEV190 and users WISE-DEV190\Administrator,WISE-DEV190\DWM-2,WISE-DEV190\DWM-1

The pool by the way is fixedThreadPool