Python: Service Loopback not working

[mariuskreutzer]

Problem Description

Hello,

im currently trying to test an module written in Python. The tests involves communicating through eCAL. Everything is done inside a single python process, if enable loopback communication everything works for pub/sub communication.

But if I try to do the same with services the applications freezes (does not even react to ctrl-c). Setting loopback has no effect (freezes with and without).

How to reproduce

I have created a minimal sample:

 import sys
import time

import ecal.core.core as ecal_core
import ecal.core.service as ecal_service


def main():
    # print eCAL version and date
    print("eCAL {} ({})\n".format(ecal_core.getversion(), ecal_core.getdate()))

    # initialize eCAL API
    ecal_core.initialize(sys.argv, "local_services")

    # set process state
    # ecal_core.enable_loopback(1)
    ecal_core.log_setlevel(1)

    # create a server for the "DemoService" service
    server = ecal_service.Server("TestService")

    # define the server method "foo" function
    def req_callback(method_name, req_type, resp_type, request):
        print("'TestService' method '{}' called with {}".format(method_name, request))
        return 0, bytes("thank you for calling foo :-)", "ascii")

    # define the server methods and connect them to the callbacks
    server.add_method_callback("foo", "", "", req_callback)

    client = ecal_service.Client("TestService")

    # define the client response callback to catch server responses
    def client_resp_callback(service_info, response):
        if service_info["call_state"] == "call_state_executed":
            print(
                "'DemoService' method '{}' responded : '{}'".format(
                    service_info["method_name"], response
                )
            )
            print()
        else:
            print(
                "server {} response failed, error : '{}'".format(
                    service_info["host_name"], service_info["error_msg"]
                )
            )
            print()

    client.add_response_callback(client_resp_callback)

    request = bytes("hello world", "ascii")

    while ecal_core.ok():
        time.sleep(1.0)
        print("Sending request")
        client.call_method("foo", request)
        print("Sent request")

    # destroy server
    server.destroy()

    # finalize eCAL API
    ecal_core.finalize()


if __name__ == "__main__":
    main()

Which results in this output (includes me killing the process):

❯ python3 combined.py
eCAL v5.13.2 (20.06.2024)

Sending request
[Service Server] [fe80::cfac:233b:f30c:78cd%wlan0:46445 -> fe80::cfac:233b:f30c:78cd%wlan0:34886] Client has connected. Using protocol version 1.
[Service Client] [fe80::cfac:233b:f30c:78cd%wlan0:34886 -> fe80::cfac:233b:f30c:78cd%wlan0:46445] Connected to server. Using protocol version 1
zsh: killed     python3 combined.py

How did you get eCAL?

Custom Build / Built from source

Environment

• eCAL Version: v5.13.2 (2024-06-20 13:23:00 +0200)
• Arch Linux (rolling)
• Python 3.12.6
• Python Package version: 5.13.2

eCAL System Information

------------------------- SYSTEM ---------------------------------
Version                  : v5.13.2 (2024-06-20 13:23:00 +0200)
Platform                 : linux

------------------------- CONFIGURATION --------------------------
Default INI              : /etc/ecal/ecal.ini

------------------------- NETWORK --------------------------------
Host name                : 
Host group name          : 
Network mode             : local
Network ttl              : 1
Network sndbuf           : 5 MByte
Network rcvbuf           : 5 MByte
Multicast cfg version    : v1
Multicast group          : 239.0.0.1
Multicast mask           : 0.0.0.15
Multicast ports          : 14000 - 14010
Multicast join all IFs   : off
Bandwidth limit (udp)    : not limited

------------------------- TIME -----------------------------------
Synchronization realtime : "ecaltime-localtime"
Synchronization replay   :
State                    :  synchronized
Master / Slave           :  Master
Status (Code)            : "everything is fine." (0)

------------------------- PUBLISHER LAYER DEFAULTS ---------------
Layer Mode INPROC        : off
Layer Mode SHM           : auto
Layer Mode TCP           : off
Layer Mode UDP MC        : auto

------------------------- SUBSCRIPTION LAYER DEFAULTS ------------
Layer Mode INPROC        : on
Layer Mode SHM           : on
Layer Mode TCP           : on
Layer Mode UDP MC        : on
Npcap UDP Reciever       : off

------------------------- EXPERIMENTAL ---------------------------
SHM Monitoring           : off
SHM Monitoring (Domain)  : ecal_mon
SHM Monitoring (Queue)   : 1024
Network Monitoring       : on
Drop out-of-order msgs   : off

[Peguen]

Hello @mariuskreutzer ,

thank you very much for reporting that bug. We found the problem that caused this issue.

It is resolved in this PR: #1760

When the builds are done you can try out the wheels from the GH Actions build or, if it is not urgent, there will we also a release with this fix coming.

Small "workaround": If you call "call_method" with a timeout like this (in ms) it also works:

client.call_method("foo", request, 100)

The behaviour differs a little bit like this, but it could unblock you.

Let us know, if the new packages resolve your issues.

Many greetings
Peter

(Windows: https://github.com/eclipse-ecal/ecal/actions/runs/11145221882/artifacts/2006308442
Ubuntu latest: https://github.com/eclipse-ecal/ecal/actions/runs/11145221882/artifacts/2006221693)

[KerstinKeller]

Implementation:

• master: [python] Call_method in service now allows threads. #1760
• v5.13: [CP #1760 > support/v5.13] [python] Call_method in service now allows threads. #1762
• v5.12: [CP #1760 > support/v5.12] [python] Call_method in service now allows threads. #1761

[mariuskreutzer]

Hello @Peguen and @KerstinKeller,

First of thank you for the swift response. I can confirm that everything works with the new wheel from the GH actions you linked.

The timeout parameter also seems to work, at least in my example application at the top.

Greetings
Marius

[KerstinKeller]

@mariuskreutzer No problem, thanks for reporting.
However, I'd recommend you to take the latest wheels build from support/v5.13 instead of the current master.
We'll also schedule a new 5.12 / 5.13 bugfix release sometime next week.