• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
netPI Desktop java
#11
Ok but why are your screen shots show that 172.17.0.3:1099 "remote object is not reachable and "connect time out". If you use IP address 192.168.160.20 - as you say - to address agent 2 ... so why do your screen shots not show 192.168.160.20 "remote object is not reachable"? I do not understand this behaviour. Please explain.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#12
(August-12th-2020, 02:08 PM)Armin @ netPI Wrote: Ok, aber warum zeigen Ihre Screenshots, dass 172.17.0.3:1099 "Remote-Objekt nicht erreichbar ist und" Verbindungs-Timeout ". Wenn Sie die IP-Adresse 192.168.160.20 verwenden - wie Sie sagen -, um Agent 2 zu adressieren ... warum also? Ihre Screenshots zeigen nicht 192.168.160.20 "Remote-Objekt ist nicht erreichbar"? Ich verstehe dieses Verhalten nicht. Bitte erläutern Sie.

Das ist unser Problem.
das verstehen wir nicht.
Der 172.17.03 ist die IP-Adresse des Containers
Portzuordnung: 1099: 1099 für die Java-Anwendung (Agent1) und 8080: 8080 für den Webdienst.
Wir können die Java-Anwendung auf dem Container jedoch nicht erreichen
  Reply
#13
Yes I realized that this is the IP address of your agent 1 container, but I think I cannot help here any further.  You know your Java application better than I. You see yourself that a simple ping command works properly and it addresses the agent 2 fine, but why your Java application is addressing the local container IP address you have to examine yourself. Maybe your Java app uses the address the "localhost" which is indeed 192.168.160.20 in the view of an app inside the container ... this is speculation only from my side ... I personally don't know the reason.

There is one additional note: If your agent 1 sends out data on port 1099 then port mapping like you configured for bridge mode it is not necessary at all. For ALL applications in a container that want to send telegrams over TCP/IP to a remote station all outgoing ports are always "open" and no port mapping is needed. A port mapping is only needed in bridged mode if an application located in an network outside the Docker host wants to reach an application inside a container on the host. But this is not the case here. You want to initiate sending data from agent 1 to agent 2 and sending works always.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#14
Since netPI's Desktop container also works on a standard Raspberry Pi you can deploy it there as well. So make a test with an RPi3 ...   I am pretty sure that you will see the very same effect and that it is not a netPI related problem.

Here is an example how to start the Desktop container on a normal Rpi3:


Code:
docker run -d --privileged --network=bridge --restart=always -e SSHPORT=23 --device=/dev/tty0:/dev/tty0 --device=/dev/tty2:/dev/tty2 --device=/dev/fb0:/dev/fb0 --device=/dev/input:/dev/input --device=/dev/snd:/dev/snd -p 23:23/tcp -p 5900:5900 hilschernetpi/netpi-desktop-hdmi
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Desktop LucioFiam 5 2,384 November-5th-2022, 10:33 AM
Last Post: Armin@netPI
  netpi-desktop-hdmi with setting network=bridge tad 13 8,091 June-19th-2020, 12:50 PM
Last Post: tad
  [SOLVED] netPI with Raspbian Desktop firefly 8 5,660 November-28th-2019, 06:01 PM
Last Post: Armin@netPI
  Auflösung in hilschernetpi/netpi-desktop-hdmi ändern dennis 5 4,193 November-15th-2018, 11:28 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)