Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guards are not evaluated when the event is fired across multiple kernels #885

Closed
gallandarakhneorg opened this issue Nov 8, 2018 · 3 comments

Comments

@gallandarakhneorg
Copy link
Member

commented Nov 8, 2018

To Reproduce
Run this code on two computers:

// First computer
package network

import io.sarl.core.DefaultContextInteractions
import io.sarl.core.Logging

event Ping
event Pong

agent PongAgent {
    uses DefaultContextInteractions, Logging
    on Ping {
    	info("pong")
        emit(new Pong)[ it == occurrence.source ]
    }
}
// second computer
package network

import io.sarl.core.DefaultContextInteractions
import io.sarl.core.Initialize
import io.sarl.core.Logging
import io.sarl.core.Schedules

event Ping
event Pong

agent PingAgent {
    uses DefaultContextInteractions, Logging, Schedules

    on Initialize {
        val task = task("waiting_for_partner")
        task.every(1000) [
            if (defaultSpace.participants.size > 1) {
                emit(new Ping)
                task.cancel
            }
        ]
    }

    on Pong {
        info("ping")
        emit(new Ping)[ it == occurrence.source]
    }
}

Expected behavior
The first agent should display "pong" indefinitely, the second agent should display "ping" indefinitely.

System configuration:
-- SARL version: 0.8.5
-- SARL compiler:

    • Eclipse compiler without Maven
      -- Java JDK version (with the manufacturer name): openjdk version "1.8.0_181"
      -- Operating System:
    • Linux 64bits

Additional context
The computers are connected on a local network with all ports opened, and Hazelcast can connect the SARL frameworks. If the guard [ it == occurrence.source ] is commented, the message is received.

Originally posted by @gbasso in #883 (comment)

@gallandarakhneorg

This comment has been minimized.

Copy link
Member Author

commented Nov 8, 2018

This issue is due to the fact that the scoping function is serialized and sent throught the network link. When the scoping function is a lambda, it cannot be deserialized properly into the target host.

We need to re-think the serialization of the scopes when it is used through a network.

Why scope is going throught network link? Because the scope is evaluated when dispatching the event inside the message transport service, i.e. inside the destination host in the case of a network-based communication.

Another issue is: Serialization of the scope breaks the links to the references to local variables inside the agent which emits the event.

Another issue is: Serialization of the scope stores the closure's classname. The corresponding class may be inexistant into the destination host virtual machine.

@gallandarakhneorg

This comment has been minimized.

Copy link
Member Author

commented Nov 8, 2018

This problem could be reproduced when using the GsonEventSerializer or the JavaBinaryEventSerializer.

gallandarakhneorg added a commit that referenced this issue Nov 18, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
gallandarakhneorg added a commit that referenced this issue Nov 18, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
@gallandarakhneorg

This comment has been minimized.

Copy link
Member Author

commented Nov 18, 2018

See the PR #888.

gallandarakhneorg added a commit that referenced this issue Nov 19, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
gallandarakhneorg added a commit that referenced this issue Nov 19, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
gallandarakhneorg added a commit that referenced this issue Nov 23, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
gallandarakhneorg added a commit that referenced this issue Nov 27, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
gallandarakhneorg added a commit that referenced this issue Nov 27, 2018
close #885

Signed-off-by: Stéphane Galland <galland@arakhne.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.