[Bug] Subscriber closes after starting a server

[IbrayevRamil]

Describe the bug

I've faced with an issue that zenoh subscribers are getting closed after starting a web-server (tried with spring-boot-tomcat, spring-boot-jetty, pure jetty).

You can use following simple code to reproduce it:

import io.zenoh.Config
import io.zenoh.Session
import io.zenoh.keyexpr.intoKeyExpr
import org.eclipse.jetty.server.Server

fun main(args: Array<String>) {
    val config = Config.Companion.from(
        """
            {
              "mode": "client",
              "connect": {
                "endpoints": ["tcp/localhost:7447"]
              }
            }
            """.trimIndent()
    )
    Session.open(config).fold(
        onSuccess = { session ->
            session.use {
                "test/test".intoKeyExpr().fold(
                    onSuccess = { keyExpr ->
                        keyExpr.use {
                            session.declareSubscriber(keyExpr)
                                .onClose { println("ON CLOSE CALLBACK IS CALLED") }
                                .reliable()
                                .with { println(String(it.value.payload)) }
                                .res()
                                .fold(
                                    onSuccess = { println("Successfully subscribed") },
                                    onFailure = { println("Failed to subscribe") }
                                )
                        }
                    },
                    onFailure = { println("Failed to get key expression") }
                )
            }
        },
        onFailure = { println("Failed to open session") }
    )
    Server(8080).apply {
        start()
        join()
    }
}

Seems like the issue not at jetty itself as different implementations of servers don't work, but in the way how servers threading lifecycle work.

Here are the logs:

Successfully subscribed
ON CLOSE CALLBACK IS CALLED
00:07:39.548 [main] INFO  org.eclipse.jetty.server.Server - jetty-12.0.6; built: 2024-01-30T02:43:24.387Z; git: 78ab6e6ba163f89cdd97f2ae0283fbb5e371cfaf; jvm 21.0.2+13-58
00:07:39.562 [main] INFO  o.e.jetty.server.AbstractConnector - Started ServerConnector@6d40861d{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
00:07:39.568 [main] INFO  org.eclipse.jetty.server.Server - Started oejs.Server@5acf93bb{STARTING}[12.0.6,sto=0] @1133ms

To reproduce

1. Create subscriber
2. Start server
3. Subscriber is getting closed

System info

• Zenoh: 0.10.1-rc
• Jetty: 12.0.6
• Kotlin: 1.9.22
• Java: 21
• CPU: Apple M3 Pro

[p-avital]

This is not a bug at all: declared elements required state to be held not only locally, but in the Zenoh network as well.

This would mean failing to undeclare an element would cause resource leaks in the infrastructure. To avoid this, all Zenoh bindings that can support doing so use destructors.

This means that if you don't store your subscribers in some variable, they will instantly be destroyed (regardless of starting a server, which has nothing to do with the issue). In garbage collected languages, delays might appear, but eventual destruction is guaranteed.

I'm closing this issue and will open another to ensure @DariusIMP documents this behaviour a bit more to avoid future conditions about this.

[IbrayevRamil]

This is not a bug at all: declared elements required state to be held not only locally, but in the Zenoh network as well.

This would mean failing to undeclare an element would cause resource leaks in the infrastructure. To avoid this, all Zenoh bindings that can support doing so use destructors.

This means that if you don't store your subscribers in some variable, they will instantly be destroyed (regardless of starting a server, which has nothing to do with the issue). In garbage collected languages, delays might appear, but eventual destruction is guaranteed.

I'm closing this issue and will open another to ensure @DariusIMP documents this behaviour a bit more to avoid future conditions about this.

Do you want to say that assigning Subscriber to a variable would resolve this issue?

[p-avital]

Correct