Local development environment broker unresponsive after IP a

Posted by jbijker on 16-Sep-2016 13:35

I have a local OE11.3 development environment on my laptop. Whenever I move between networks (e.g. between office / client) and getting a new IP address my admin server used to be unresponsive until I've forced it to bind to localhost by editing $DLC/properties/AdminServerPlugins.properties, under section [PluginPolicy.Progress.AdminServer]:
1) Add -Djava.rmi.server.hostname=localhost to the jvmargs line
2) add a new line args=-host localhost

This works great, but I still have a problem with stopping / starting brokers after an IP address change. This is what I get in the admin server log file:
* AdminServer GUI Plugin internal error 2: SvcControlCmd.pingService(wsb_1501pre) failure: java.rmi.ConnectException: Connection refused to host:; nested exception is:
*     java.net.ConnectException: Connection timed out: connect (8172)(java.rmi.ConnectException: Connection refused to host:; nested exception is:
*     java.net.ConnectException: Connection timed out: connect)

IP address is the IP address I was connected to but is no longer reachable. Any idea why it's using that IP address instead of localhost?

Whenever the broker gets started it runs $DLC\bin\jvmStart with a lot of parameters. I guess somehow I need to add -Djava.rmi.server.hostname=localhost to this but have no idea how.

Any pointers?

All Replies

Posted by Matt Baker on 16-Sep-2016 13:58

By default java RMI binds to the IP address.  This is java default behavior.  And it is annoying for exactly the reason you describe.
Have you tried using the real hostname instead of ‘localhost’.
You can also start the adminserver with -host <hostname> which will do the same thing without having to edit the properties file (it sets java.rmi.server.hostname for you).

Posted by Stefan Drissen on 16-Dec-2016 07:29 / Windows 10 x64

I have added -host MARS to the registry AdminServer startup chimera:

"c:\progress\oe11.6\bin\jvmstart" -a "c:\progress\oe11.6\properties\AdminServerPlugins.properties"::PluginPolicy.Progress.AdminServer -o eventmgr -w @{WorkPath} @{JAVA\JREHOME}\bin\java -DInstall.Dir=@{Startup\DLC} -DWork.Dir=@{WorkPath} -Dadmsrv.jvm=@{JAVA\JREHOME}\bin\java -Djvmstart.debug=0 com.progress.chimera.adminserver.AdminServerType -host MARS -start -service

My WebSpeed broker starts fine:

[2016/12/16@00:22:31.162+0100] [3] [OpenEdge]              c:\progress\oe11.6\bin\jvmStart -w c:\tfs\ef72\2\work -o stdout -e 1 c:\progress\oe11.6\jre\bin\java -classpath c:\progress\oe11.6\jdk\lib\tools.jar;c:\progress\oe11.6\java\progress.jar -DInstall.Dir=c:\progress\oe11.6 -Djava.security.policy=c:\progress\oe11.6\java\java.policy -DCanonicalName=fathom1.mars:ID=WebSpeed com.progress.ubroker.broker.ubroker -t WS -i ws722openedge-r -r rmi://MARS:20931/ws722openedge-r -f c:\progress\oe11.6\properties\ubroker.properties

But when my IP address has changed, a wtbman query results in:

[2016/12/16@14:19:59.434+0100] [3] [STDERR]                java.rmi.ConnectException: Connection refused to host:; nested exception is:

[2016/12/16@14:19:59.434+0100] [3] [STDERR]                 java.net.ConnectException: Connection timed out: connect

The IP address in the error is the old and not my current IP address. I thought the -host addition was supposed to ensure that a host name is used instead of an (old) IP address?

Posted by jbijker on 28-Dec-2016 07:39

In the end I've settled to a VM running all my local environments. Most VM software packages will give your VM a IP address which does not change when using a "Host only" of even "NAT" network interface.

In my case I'm using a CentOS VM while I still use the development tools in Windows. It's possible to store all the code on the VM and access it via a Samba share, or the other way round with a windows share, but that's very slow in both cases. So what I'm doing now is to host all the code on my Windows host, and make use of shared folders to access the code from the VM. Virtualbox's shared folders functionality is slow, VMWare Player was the best I could find. Hyper-V doesn't support shared folders at all. All DBs & agents I'm hosting on the VM, but I guess you could host the DBs on Windows too and connect to them via an IP address - most likely at a performance penalty.

Posted by jbijker on 28-Nov-2017 01:45

Update: With Windows 10 Anniversary edition Subsystem for Linux (WSL) support of filesystem notification events (inotify events), you can use lsyncd from bash to sync any changes on the windows side to your VM over rsync. This implies you have copies of your code on Windows and on your VM, but the performance is absolutely great on both sides.

This thread is closed