|
POST
|
Thanks Chris. I am not sure if there are any consequences of the certificates missing from one of the Portal machines. We are about to do full HA/DR testing so we might find out then.
... View more
02-04-2020
02:59 PM
|
0
|
2
|
2872
|
|
POST
|
We are running a single machine GeoEvent 10.6.1 (10.6.1.9310, 10.6.1.9310 - 10.6.1 Patch 1, 10.6.1.9301 - 10.6.1 Hotfix 1) and have a situation where the data is old by the time it is being written to the db. We set the logs to debug and noticed that the timestamp in the outgoing message was at times an hour old against the time noted in the logs, shown below. 2019-10-08T15:35:17,660 | DEBUG | HttpRequest Worker Thread: https://xxx/gissite/rest/services/xxx/FeatureServer/0/updateFeatures | wire | 53 - com.esri.ges.framework.httpclient - 10.6.1 | http-outgoing-5061669 >> "f=json&token=xxx&features=%5B%7B%22geometry%22%3A%7B%22x%22%3A145.28335%2C%22y%22%3A-38.11364%2C%22spatialReference%22%3A%7B%22wkid%22%3A4326%7D%7D%2C%22attributes%22%3A%7B%22radioid%22%3Axxx%2C%22timestamp%22%3A1570505632872%2C%22infotype log time 2019-10-08T15:35:17,660 vs timestamp of 1570505632872 (2019-10-08T14:33:53) I don't think there is a delay between the input and output connector and would like to check that there is no backlog prior to the input connector. I have checked the :6443/arcgis/admin/system/platformservices status {"configuredState": "STARTED", "details": [{ "machine": "xxx", "realtimeState": "STARTED"}]} and health - the result of which I am assuming is ok {"xxx": {}} The GeoEvent Monitor shows the same rate and "time since last" for the input and output. The machine CPU and memory is low at around 20% and 38% respectively. Does anyone have any tips on where else I could look for clues as to the internal performance of this GeoEvent service please? TIA.
... View more
10-08-2019
04:54 PM
|
0
|
4
|
1824
|
|
POST
|
We are running GeoEvent 10.6.1 (10.6.1.9310, 10.6.1.9310 - 10.6.1 Patch 1, 10.6.1.9301 - 10.6.1 Hotfix 1) I am trying to access https://machine.domain:6143/geoevent/rest/ and https://machine.domain:6143/geoevent/admin with both returning a "The website cannot display the page" message. The admin page redirects to create a token and then displays this message. Are the alternative addresses that I should be trying?
... View more
10-08-2019
04:33 PM
|
0
|
0
|
543
|
|
POST
|
Thanks Jonathon, so just to clarify, it isn't an indication that one machine has lost its sync with the shared config? As we have an automated deployment I am sure that the certificates would have been applied on install to each machine, I will double check, but can I ask if there is a known circumstance where a machine 'loses' a certificate?
... View more
10-07-2019
03:03 PM
|
0
|
6
|
2872
|
|
POST
|
I am troubleshooting some issues and came across differences between machines in our Portal HA and am wondering how to "sync" or force the one I think is correct to update the other. When I go to machine1/arcgis/portaladmin/security/sslCertificate I have two certificates with one missing (machine one is standby) When I go to machine2/arcgis/portaladmin/security/sslCertificates I have the correct three certificates (machine two is primary) (In a testing environment the same issue exists but the one with the correct certificates is the standby machine) There is also a question of what else is different that I cannot see. At this stage the index is the same. I am thinking that a "sync" button to force the config on each machine to update will fix the issue? or something similar? I didn't want to just add in the missing certificate to the first machine in case there were other differences that I wasn't aware of.
... View more
10-06-2019
08:18 PM
|
0
|
8
|
3053
|
|
POST
|
The answer can be found here... Querying Feature Services: Date-Time Queries
... View more
09-16-2019
10:16 PM
|
0
|
0
|
1252
|
|
POST
|
We have a verified site again after a couple of re-installs. Yay.However a couple of things we are raising as a support ticket to determine whether we need to be worried about in terms of the long term stability and resiliency of the site. The no valid keystore error is still present in the logs, but we now think that is potentially a trigger for it to create the geoevent keystore, not 100% sure. We still are getting the "signed field invalid" error too. But given that the site is verified in the browser and is processing data to expectations, we are not sure whether this is a true error or if it will have any bearing on the functioning or stability of the site. One concern is the number of bad http warnings we are getting as well as connection to the http 6080 help page. not sure what the bad http warnings are for, they are present when there are no services. how do we turn off the software trying to connect to the http help page (the site is configured to https only) 2019-08-07T10:08:21,971 | WARN | qtp1787802408-35708 | HttpParser | 407 - org.eclipse.jetty.util - 9.3.14.v20161028 | Illegal character 0x16 in state=START for buffer HeapByteBuffer@3afa250b[p=1,l=176,c=8192,r=175]={\x16<<<\x03\x01\x00\xAb\x01\x00\x00\xA7\x03\x03\xEf\x8f\xAd\xC2\x1eP\x9d...\x02\x04\x03\x03\x01\x03\x02\x03\x03\x02\x01\x02\x02\x02\x03>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00} 2019-08-07T10:08:21,971 | WARN | qtp1787802408-35708 | HttpParser | 407 - org.eclipse.jetty.util - 9.3.14.v20161028 | bad HTTP parsed: 400 Illegal character 0x16 for HttpChannelOverHttp@589160c6{r=0,c=false,a=IDLE,uri=null} 2019-08-07T10:08:23,367 | ERROR | qtp1787802408-35565 | Http | 53 - com.esri.ges.framework.httpclient - 10.6.1 | Second attempt failed. Giving up. (http://LB + domain :6080/arcgis/help/en/cxhelp.xml --- Connect to LB + domain :6080 [LB + domainl/ip address] failed: Connection timed out: connect) 2019-08-07T10:08:23,367 | INFO | qtp1787802408-35565 | Http | 53 - com.esri.ges.framework.httpclient - 10.6.1 | Connect to LB + domain:6080 [gis-uat-ge.vicpolice.internal/ip address] failed: Connection timed out: connect
... View more
08-06-2019
05:14 PM
|
0
|
0
|
2370
|
|
POST
|
This is no longer an issue. We ended up re-installing GeoEvent after removing all ESRI artifacts including registry files (risky, but for us it was worth it). One thing we noticed that on the previous install only the service account name had been entered during the installation process of ArcGIS Server and GeoEvent. This created a different Windows User folder, and even though it was accepted by Windows authentication with the same credentials, there was obviously something "different" about it. On re-installing we entered the service account as domain\account-name. So two things that I think contributed to fixing this issue: 1. entering the service account as domain\account-name 2. After federating, I made sure that I reset the configuration (there was some ambiguity as to whether this step was done on the previous failed install). This install meant that the default Portal connection was valid from the start with no editing required from us. It also seemed to fix the issue where a feature service layer couldn't be access by the output connector. Unfortunately it didn't fix our "signed field invalid" issues blogged here. (I have create an ESRI support case as to whether we need to pursue fixing these) Hopefully this helps someone else.
... View more
08-06-2019
05:02 PM
|
0
|
0
|
2243
|
|
POST
|
Thanks for the reply. There is no account registered for either Portal or Server to connect as Data Stores. Prior to this move it seemed to be ok without any credentials. There are no logs in ArcGIS Server as the message never makes it to the rest endpoint. Despite being able to select the service in the manager for the output connector, GeoEvent can no longer delete or write features.
... View more
08-05-2019
08:14 PM
|
0
|
0
|
2243
|
|
POST
|
We have another log error that I am not sure whether it is related to SSL certs, keystores and config-stores. A bit of background, we moved our config-store, Portal and Server came back up fine. GeoEvent did not, the browser changing from a secure connection to unsecure and having to add a security exception to view the manager. We weren't able to fix the issue (see this question), so we re-installed, and despite the browser now saying the connection is secure again, we are still seeing in the karaf logs, entries such as "no valid keystore" and "Failed to read certificate file... signed fields invalid". I tried to send through a test message and a log entry was added to say that the user didn't have permissions "2019-08-05T16:35:02,510 | ERROR | FeatureJsonOutboundAdapter-FlushingThread-com.esri.ges.adapter.outbound/JSON/10.6.1 | FeatureServiceOutboundTransport | 78 - com.esri.ges.framework.transport.featureservice-transport - 10.6.1 | {"error":{"code":400,"message":"User does not have privileges to perform this operation.","details":[]}} 2019-08-05T16:35:02,511 | ERROR | FeatureJsonOutboundAdapter-FlushingThread-com.esri.ges.adapter.outbound/JSON/10.6.1 | FeatureServiceOutboundTransport | 78 - com.esri.ges.framework.transport.featureservice-transport - 10.6.1 | Error while writing to feature service VRN-Device-Locations. Error: {"error":{"code":400,"message":"User does not have privileges to perform this operation.","details":[]}}." I have a feeling that the certs and this user permission error may be linked, but I am not sure how. I wasn't able to see any owners of the output connectors in GeoEvent (the config xml has owners for the definitions), and the owner of the item in Portal is a valid user. How can I tell/change which user GeoEvent is using to write to the feature service? Is this the service account? (I am assuming so??) Does the feature service need to have the same owner as the GeoEvent user? (they would have been when first published, but would just like to double check since the config-store and directories move) I also have another feature service where GeoEvent can't see the layer within. This layer does exist in the AGS services directory. At this stage the only solution I have for this problem is to re-publish the service, however given the other issues, I am wondering whether it is all linked.
... View more
08-05-2019
12:45 AM
|
0
|
3
|
2641
|
|
POST
|
Thank you Minbin Jiang unfortunately that didn't help in our instance. Appreciate the suggestion though.
... View more
08-04-2019
06:46 PM
|
0
|
0
|
2370
|
|
POST
|
We are on GeoEvent 10.6.1 (no patches) and have been required to move the config-store and directories to a new share. I used the ArcGIS Server admin>system>configstore and directories edit functions to do this. Upon completion the ArcGIS Server Manager opens correctly as a verified site with the correct certificates being shown. However, opening the GeoEvent Manager the browser warns that "Your connection is not secure. The owner of xxx has configured their web site improperly". Prior to the config-store and directories move, the Manager opened correctly. I restarted the server and upon start up the following was in the karaf logs 019-07-31T14:46:00,121 | ERROR | CM Configuration Updater (ManagedService Update: pid=[org.apache.cxf.osgi]) | HttpServiceStarted | 443 - org.ops4j.pax.web.pax-web-runtime - 6.0.3 | Could not start the servlet context for context path [] java.lang.IllegalStateException: no valid keystore 2019-07-31T14:46:01,965 | ERROR | pool-3-thread-1 | HttpClientService | 53 - com.esri.ges.framework.httpclient - 10.6.1 | Failed to read certificate file at xxx-ags.pfx.cer: signed fields invalid 2019-07-31T14:46:01,990 | ERROR | pool-3-thread-1 | HttpClientService | 53 - com.esri.ges.framework.httpclient - 10.6.1 | Failed to read certificate file at xxx-ge.pfx.cer: signed fields invalid The certificates do exist where the error is pointing to and from what we can tell are all ok. The arcgis.keystore matches the certificates that are installed on the machine (Windows 2012 under the Personal certificate folder, not the Trusted Root Certification Authorities folder - is this an issue?? not sure why moving the config-store would cause this to be an issue if it worked before) Following the suggestions in 206700-geoevent-server-1051-no-service-was-found and RJs admin reset (which has been my go to geoevent fix until now) did not resolve the issue. Am I correct in thinking that because the ArcGIS Server Manager is verified correctly that the arcgis.keystore under Program Files\ArcGIS\Server\framework\etc\certificates\arcgis.keystore is ok. However, GeoEvent is somehow not creating the C:\ProgramData\ESRI\GeoEvent\certs\geoEventSSLCertificate.jks correctly? The answer is probably not important, but how to fix it if it is the issue. Any ideas on where to go to from here please???
... View more
07-31-2019
01:25 AM
|
0
|
3
|
2839
|
|
POST
|
Hi Shaikh, I realise that this was a while ago now, but do you remember how you set the "cluster radius properly"? Thanks, Gill
... View more
06-05-2019
03:33 AM
|
0
|
2
|
833
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-19-2024 07:15 PM | |
| 1 | 05-15-2019 02:05 AM |
| Online Status |
Offline
|
| Date Last Visited |
a month ago
|