@workers not as expected.

[nathand...@gmail.com]

I have a quite crude simulated worker to model high data processing.

In the production environment there will be mass data processing calls which
are independent and can take up to a minute. To model this I've created a rough method called longtask which will take a minute to complete.

@Workers(10)
@Service
public class Application {
private static AtomicInteger workerCount = new AtomicInteger();

@Get
public void shorttask(Result<String> result) {
System.out.println("short");
result.ok("short");
}

@Get
public void longtask(Result<String> result) throws InterruptedException {
int worker = workerCount.get();
workerCount.incrementAndGet();
System.out.println("worker " + worker + " started.");
for (int i = 0; i < 100; i = i + 10) {
System.out.println("worker " + worker + " " + i);
Thread.sleep(6000);
}
System.out.println("worker " + worker + " finished.");
result.ok("worker " + worker + " finished.");
}

public static void main(String[] args) throws Exception {
Web.include(Application.class);
Web.go(args);
}
}

Not scheduling as expected...
I invoke the service methods via curl.
Run:
longtask -> 500ms(wait) -> longtask -> 500ms -> longtask -> 500ms ->
longtask -> 500ms -> shorttask -> 500ms -> longtask

worker 0 started. |
worker 0 0 |
worker 0 10 | Why have the other workers not started?
worker 0 20 |
worker 0 30 |
short <- ~20 seconds before another task is started? <-
worker 1 started. Why such a long delay? |
worker 1 0 |
worker 2 started. <- Here workers 0, 1 and 2 are running. |
worker 0 40 |
worker 2 0 |
worker 1 10 |
worker 0 50 |
worker 2 10 |
worker 1 20 |
worker 0 60 |
worker 2 20 |
worker 1 30 |
worker 0 70 |
worker 2 30 |
worker 1 40 |
worker 0 80 |
worker 2 40 |
worker 1 50 |
worker 0 90 |
worker 2 50 |
worker 1 60 <- active workers: 0, 1, 2 |
worker 0 finished. <- active workers: 1, 2 |
worker 3 started. <- active workers: 1, 2, 3 |
worker 3 0 Max workers of 3? Why? |
worker 2 60 |
worker 1 70 |
worker 2 70 |
worker 3 10 |
worker 1 80 |
worker 3 20 |
worker 2 80 |
worker 1 90 |
worker 2 90 |
worker 3 30 |
worker 1 finished. |
worker 4 started. <- Still max number of workers = 3 |
worker 4 0 |
worker 3 40 |
worker 2 finished. |
worker 4 10 |
worker 3 50 |
worker 4 20 |
worker 3 60 |
worker 4 30 |
worker 3 70 |
worker 4 40 |
worker 3 80 |
worker 4 50 |
worker 3 90 |
worker 4 60 <- Received message from shorttask 96 seconds <-|
worker 3 finished. after it has complete. Why?
worker 4 70
worker 4 80
worker 4 90
worker 4 finished.

run 2:
longtask -> 500ms(wait) -> longtask

worker 0 started.
worker 0 0
....
worker 0 90
worker 0 finished. <- finished but not received message.
worker 1 started.
worker 1 0
....
worker 1 90
worker 1 finished. <- Both complete and received sent response message
at same time, but worker 0 completed 60 seconds ago?

Is this not supposed to be multithreaded?
This has taken 2 minutes when is should have only taken 1.

Is this supposed to happen?
Is there a way to configure the service to start multiple calls at once
and without a long delay and respond immediately when finished?

Any ideas or comments?
Thanks.

[Alex Rojkov]

Your are correct. Sometimes the responses get batched. I am filing an
issue report.

Thanks,
Alex

> --
> You received this message because you are subscribed to the Google Groups "Baratine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to baratine-io...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alex Rojkov]

FYI: Issue report is at https://github.com/baratine/baratine/issues/18

Alex

[nathand...@gmail.com]

Thanks for the response.
Is the maximum of 3 method instances normal as well? 10 threads have been have been listed for the class. Also including the long delay before threads are dispatched after the first thread?

I have been looking at other frameworks like MSF4J and KumuluzEE.
Baratine seem to be the best fit for my requirements. While the more feature rich alternatives I've tried such as Wildfly Swarm and Vert.x are a bit resource hungry.

Thanks.