Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Problem with single execution services #516

@Jonaythaz

Description

@Jonaythaz

Services with single as the execution modality shut down before one-way operations finish executing.

I initially encountered this problem while testing making calls to the embedder from a Java service, but I was also able to reproduce the problem with the following Jolie code (running in a devcontainer with the jolielang/jolie:1.12.0-dev image):

from console import Console
from time import Time

interface PrinterInterface {
    oneWay: printSomething(void)
}

service Printer {
    embed Console as Console
    embed Time as Time
    
    execution: concurrent

    inputPort ip {
        location: "local"
        interfaces: PrinterInterface
    }

    main {
        [ printSomething() ] {
            sleep@Time(3000)()
            println@Console("Hello World!")()
        }
    }
}

service Main {
    embed Printer as Printer

    main {
        printSomething@Printer()
    }
}

Running the Main service of this program is supposed to print "Hello World!" to the console, and does in fact do so when the line sleep@Time(3000)() isn't included, but when the execution time of the one-way operation is too long the program seemingly just stops before it finishes executing.

From looking into the problem it seems that the cause is that, when the execution modality of a service is single, the exit method of the Interpreter class is called once all request-response operations finish executing. The reason this is a problem is because the exit method causes all the executors to shut down, meaning that when the one-way operation tries to have some work executed, in this case the println operation, the executor it is trying to have execute the operation is shutting down, or already terminated, and therefore refuses the work.

I did also try to see if there was a simple way to solve the problem, but the furthest I got was that the problem seems to have something to do with how the SessionThread, or perhaps even ExecutionThread, class is implemented, since, best I can tell, the exit method is called once its join method returns in the runCode method of the Interpreter class.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions