Hello!
I'm checking if Lightstreamer will work for my organization, but I'm running into problems
I've been attempting to get Lightstreamer and a .NET-based remote adapter set (one metadata + one data) working together in a set of containers on my machine via docker-compose, however the Lightstreamer server appears to be rejecting connections from the remote adapters.
Here's my docker-compose file. I'm confident that the compose file is correct-- I'm really just providing it as a concise way to describe the containers at play:
version: "3"
services:
daemon:
image: lightstreamer
ports:
- "8080:8080"
authentication:
build: authentication
environment:
- LS_HOST=daemon
- LS_PORT_REQREP=9001
- LS_PORT_NOFITY=9002
links:
- daemon
dummydata:
build: dummydata
environment:
- LS_HOST=daemon
- LS_PORT_REQREP=9011
- LS_PORT_NOFITY=9012
links:
- daemon
authentication and dummydata are modeled closely after the example .NET ARI adapter on GitHub (
https://github.com/Lightstreamer/Lightstreamer-example-HelloWorld-adapter-dotnet). The metadata adapter server, as implied by the compose file, attempts to connect to Lightstreamer over port 9001 for requests and replies. The data adapter, similarly, attempts to connect to Lightstreamer on ports 9011 (request-response) and 9012 (notify).
I left lightstreamer_conf.xml untouched, and created a new adapter config, adapters/dummydata/adapters.xml :
<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not remove this line. File tag: adapters_conf-APV-20200124. -->
<adapters_conf id="PROXY_SOCKET_ROBUST">
<metadata_adapter_initialised_first>N</metadata_adapter_initialised_first>
<metadata_provider>
<install_dir>metadata</install_dir>
<adapter_class>ROBUST_PROXY_FOR_REMOTE_ADAPTER</adapter_class>
<classloader>log-enabled</classloader>
<param name="request_reply_port">9001</param>
<param name="interface">authentication</param>
<param name="auth">N</param>
<param name="connection_recovery_timeout_millis">10000</param>
<param name="first_connection_timeout_millis">10000</param>
<param name="close_notifications_recovery">unneeded</param>
<param name="notify_user_disconnection_code">-10</param>
<param name="notify_user_disconnection_msg">Remote Metadata Adapter unavailable</param>
</metadata_provider>
<data_provider name="MY_REMOTE">
<install_dir>myadapter_one</install_dir>
<adapter_class>ROBUST_PROXY_FOR_REMOTE_ADAPTER</adapter_class>
<classloader>log-enabled</classloader>
<param name="request_reply_port">9011</param>
<param name="notify_port">9012</param>
<param name="interface">dummydata</param>
<param name="tls.remove_cipher_suites.1">_DHE_</param>
<param name="tls.enforce_server_cipher_suite_preference">Y</param>
<param name="tls.enforce_server_cipher_suite_preference.order">JVM</param>
<param name="tls.allow_protocol.1">TLSv1.2</param>
<param name="auth">N</param>
<param name="connection_recovery_timeout_millis">10000</param>
<param name="first_connection_timeout_millis">10000</param>
<param name="events_recovery">use_snapshot</param>
<param name="status_item">remote_adapter_status</param>
<param name="missing_connection_timeout_millis">10000</param>
</data_provider>
</adapters_conf>
After all this, when I run docker-compose up I get a .NET error message from both of my adapters saying that Lightstreamer has refused to connect. Here you can see that my adapter resolved daemon as 172.23.0.2:
dummydata_1 | System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (111): Connection refused 172.23.0.2:9011
dummydata_1 | at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
dummydata_1 | at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
dummydata_1 | at System.Net.Sockets.Socket.Connect(IPAddress address, Int32 port)
dummydata_1 | at System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
dummydata_1 | --- End of stack trace from previous location where exception was thrown ---
dummydata_1 | at System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
dummydata_1 | at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port)
dummydata_1 | at LightstreamerDummyDataProvider.Program.AttempTcpClient(String host, Int32 port) in /src/LightstreamerDummyDataProvider/LightstreamerDummyDataProvider/Program.cs:line 31
I've written my adapters to try for a good 15 seconds or so to connect to the Lightstreamer daemon, so I'm confident this isn't happening because Lightstreamer just isn't ready to receive connections yet.
I double-checked that my networking assumptions about docker-compose were correct, and they are-- when I added an httpd-based service called "web" to the services, my remote adapters were able to connect to it as
http://web:80 without issue. I also verified that my adapters were able to resolve "daemon" as an IP, which I confirmed they were. This all leads me to believe that Lightstreamer is responsible for rejecting my adapters. I followed the ARI documentation all the way through, however I feel like there's just some additional configuration I'm missing, or that perhaps there's something about docker-compose that messes with Lightstreamer. If it would help, I can provide my repo as a runnable example.
I figured maybe I'd have more luck running Lightstreamer and the remote adapters non-virtualized, just as vanilla processes on my local machine speaking to each other, however running Lightstreamer outside of a container on Windows is also giving me an error citing an unreadable path (it doesn't say which path is the problem). It says to check the logs for more info on what when wrong, but then I look in the logs directory and it's empty. At this point I figured it was time to reach out for help.
Any and all help would be appreciated. Thanks!
