I’ve recently started getting this problem on 2 different servers when launching the hmi from jnlp files. (Apologies for creating a new topic on this as I just noticed there is another with similar title further down the screen)
It is possible it is our network or internal firewall software but I’ve started getting complaints from operations regarding this occurring when starting the hmi. Sometimes it takes multiple attempts before it link works.
Error launching application:
ConnectionException: Connection refused: connect
or
HttpResponseException: 404: Not Found
I can reproduce the latter sometimes but not always on my laptop. The latest report is that the former occurred after logging out and then immediately trying reopen the HMI.
On my own machine when the 404 response occurs and I connect wireshark and monitor the network, I see it contacting the wrong server for information in the middle of the process. We are not using clustering on these machines and the gateway name is different. I was also starting the JNLP files manually by running javaws directly on jnlp files which have the correct server information. Really I do not know how the the production server knows about the development server in this context but it does. I did find reference in the xopcua module configuration keystore but assume that should not be related.
The projects are being transfered from one server to another by downloading and uploading to another server. It sounds like some sort of javaws caching problems on my local machine if I am interpretting this correctly. It is not 100% consistent so not clear what is going on.
Anyway, I suspect this is not adequate information to investigate but is there anything I can do to enable better logging when starting up.
Well I took a look at the client caching system and found a bug that might have caused this behavior, but it seems unlikely to me. I’ve fixed it for the next release, so we’ll have you try that when it is available.
I’m not totally clear on what HTTP server it is trying to contact. Is it some random address (i.e. not an Ignition server) or is it your other server?
Do you have the Autodetect HTTP Address setting un-checked (under Redundancy), with the wrong server name filled in by any chance?
I have Autodetect HTTP Address enabled on the servers. The redundancy settings are untouched I believe. I have changed the gateway name though.
Edit: Additional notes on this. I deleted the .ignition folder on my laptop last week or so and I think it made the problem much worse like it fails most of the time now but only for me. But then again I also synchronized projects recently as well so if its a caching thing that could be related.
Will note that there are many C_.txt files in my cache folder. This file contains IP Addresses to my development server but this is usually the server it seems to try to contact after the first servers fail to connect.
Another note is that the development server is running latest beta software as well as it has the OEE module (which I think is unrelated) and the ActiveX module (this module seems to be causing jniwrap.log files to be created so could be doing other things?). The production servers are still on 7.1.8-b3.
I am seeing a similar problem. Running 7.2.3 (b6630). I can launch the application from Designer in full-screen mode without error, but I get errors when I try to launch it in either windowed (staging) or windowed (published) modes. It doesn’t happen every time, but is frequent. The error message is attached.
Just reread your response Carl and I think only responded to the final item. I will also be clear that I think what I reported is probably 2 different issues. The connection refused item was reported by our operators is one and the 404 is one that happens to me I think exclusively.
We have 2 production servers at 2 different sites and 1 development server. Edits are made by one designer on one of the production servers and synchronized to the other server manually every once an a while. I update the development server from the production server occasionally. We just download the project and upload and overwrite the other server occassionally. They make changes to the one production server all of the time so its hard to keep track of I know I am frequently out of date when connecting. Not sure if that could make a difference.
The connect refused issue could be anything including our network or the user jumping between wifi and lan or something though he indicated that he was not doing that. That could be our network misbehaving or his machine. The log file from his .ignition folder shows it getting a Connection reset while downloading edits and then getting refused connections afterwords.
The 404 error happens on my machine I think and only when I try to connect to the production servers and rarely if ever on the development server. My logging shows that the first attempt is made to the production server but subsequent attempts are made against the development server which fails because it has no idea what session is being requested.
I did some logging with procmon and can see that instances when it succeeds is when it looks for a CProject_HASH.txt and fails to find the file. Cases when it fails is when it does find that file. There are about 11 of those files there now and there were 16 before removing the cache folder. The contents of that file are pointing to my development server.
Each time I launch the client it seems to look for a different txt file.
I don’t know if todd.be had any success overcoming this. I still see this issue on some client machines, but not all. I never get the 404 not found error message, just the error message I posted previously about connection refused. Now running 7.2.5-beta3. Thanks.
The 404 problem seems to be resolved for me in the current beta (7.2.5-b3). I cannot say about the connection refused issue as that was never a reproducible problem for us.
There was a problem with multi-nic servers that caused the clients to be fed the wrong gateway address, which would then be stored in the CProject_Hash.txt files, and then subsequent launches would use this cached address and fail. This was fixed for 7.2.5.
