|
POST
|
Hello Adam - I've received some information on your question I can share. I don't have any first-hand experience with VMware replication, but there are some architecture consultants within Esri Professional Services who do. Your customer service representative could help put together a consulting engagement, if that is something you would like to pursue. Please reach-out to me off-forum and I'll provide you with some names for consultants with experience in this area. Speaking generally, VMotion is something that you would want to integrate within the data center. VMware vCenter's Site Recovery Manager (SRM) is used to move your VMs to the Disaster Recovery site and spin them up. VMotion can create the VMs and SRM can then move these VMs to DR to establish a similar enterprise GIS operational environment. The Esri architecture consultants who responded to me have some documentation for implementing DR, but a lot of the consulting is identifying exactly what you are trying to accomplish. Here are some considerations you may need to address: Data currency and ArcGIS Server site configuration. If you have a primary data center it is relatively easy to maintain a DR site at same operational level with a slightly different server configuration. For example, N+1 fault-tolerant servers are not normally deployed within a disaster recovery site. With ArcGIS Server deployments, changes made to your primary data center can be replicated to your DR. For the most part this is a static set of operations and DR can take advantage of primary data center licensing. Maintaining your Desktop operational environment. This can be a challenge when the data being used is consistently changing. For example, if analysts need the ability to continue data editing and service publication tasks from where they were when the primary site went down, snapshots or replication of changes must also be moved to DR. This can be done during data center operations, but it requires additional licensing. Portal for ArcGIS is another dynamic that needs to be incorporated into the VMotion and SRM environment. You'll have to implement monitoring for facility failure and either manually or automatically switch the Portal configuration to reroute requests from the primary data center to the DR data center. Hope this information helps - RJ
... View more
06-22-2015
12:01 PM
|
1
|
0
|
789
|
|
POST
|
Hello Thibaut - The behavior you are seeing is by design. Please take a look at a blog I just posted: Understanding GeoEvent Definitions. It seems there have been a few questions in this area lately. The GeoTagger processor is one of the processors which will add a field to the event it is processing. Adding or removing fields from an event changes the event's structure, requiring the processor making the change to construct a new GeoEvent Definition. I tend to refer to these as "managed" GeoEvent Definitions since they are owned by the processor and will be deleted when changes are made to the GeoEvent Service and the service is republished. The location of the processor within the GeoEvent Service does not matter. It could be located immediately before an output (as you indicate your GeoTagger is) or further "upstream" closer to the input node. The processor owns the GeoEvent Definition it creates and the processor will delete its GeoEvent Definition if it believes it to be stale and will wait to receive an event before creating a new GeoEvent Definition. Hope this information helps - RJ
... View more
06-05-2015
03:54 PM
|
1
|
1
|
3448
|
|
POST
|
Hello Brad - Yes, if a GeoEvent Definition exists in a product configuration, but a processor feels that it needs to create one, it is possible that you will find what appear to be duplicate GeoEvent Definitions listed by the GeoEvent Manager after event data has been processed by one of your GeoEvent Services. It is also possible that two different processors, in two different GeoEvent Services, have been configured to create a GeoEvent Definition with the same name, producing what appears to be duplicates in the Manager's GeoEvent Definitions list. If you use GeoEvent Manager to select and delete a GeoEvent Definition a processor owns and needs, the processor should recover by re-building the GeoEvent Definition when it next receives an event to process. You might find information identifying which GeoEvent Definitions are associated with which processors in a GeoEvent Service by reading through an XML export of a GeoEvent configuration. Notice in the illustration below that the GeoEvent Service has "nodes", one of which is a processor, and the processor has properties. Usually, however, I just look at the XML to see if it is importing a GeoEvent Definition for me, delete any GeoEvent Definitions I don't think I need after importing the XML, then run a few test events through the GeoEvent Service to see which GeoEvent Definitions get created. As a general rule, I try not to include "managed" GeoEvent Definitions (those created by a processor or inbound connector's adapter) in the XML configurations I export. I try to make copies of event definitions I need and let processors / adapters create fresh event definitions for what they need on-the-fly. Hope this information helps - RJ
... View more
06-05-2015
03:41 PM
|
0
|
0
|
1532
|
|
BLOG
|
Understanding what a GeoEvent Definition is and how they are created is important for understanding the real-time analytics, filtering, and processing being performed by a GeoEvent Service. In the Making Features Come Alive exercise in Module 2 of the Introduction to GeoEvent tutorial, you are introduced to the Field Mapper Processor. One of your first experiences with GeoEvent Definitions will probably be when using a GeoEvent Service to add or update features in a feature service’s feature layer. Mapping a GeoEvent to a schema consistent with the feature layer before sending an event to an output to add/update features is a recommended best practice. You should think of every GeoEvent as having an associated GeoEvent Definition. An input connector does not receive GeoEvents. The connector has a transport which receives and hands-off a byte stream to the connector’s adapter. The adapter needs a GeoEvent Definition in order to instantiate different data values and place the data into different fields within a data structure. It’s like the adapter is sorting mail -- this field is a String, that field is a Date, that other field is a Long integer,… etc. The structure of a GeoEvent is specified by a GeoEvent Definition. Several input connectors available out-of-the-box with the GeoEvent Extension use adapters which allow you to determine whether the adapter should create a GeoEvent Definition. The adapter does this by taking the first event received, examining the data values, and then making a best-first-guess at what the GeoEvent Definition should look like. If a GeoEvent Definition already exists with the name you specified, the adapter will use (not update) this existing GeoEvent Definition. GeoEvent Definitions have owners. When an adapter creates a GeoEvent Definition for you the owner will look something like: auto-generated/com.esri.ges.adapter.inbound.JSON If you copy an existing GeoEvent Definition, import a GeoEvent Definition from a feature service, or click 'New GeoEvent Definition' to create one from scratch, the GeoEvent Definition owner will typically be displayed as either arcgis (10.2.x) or admin (10.3.x) depending on how you logged in to ArcGIS GeoEvent Manager. Only two GeoEvent Definitions come defined out-of-the-box. The incident GeoEvent Definition owner is identified as com.esri.ges.processor/IncidentDetector/xxxx. You can see this if you click to examine the incident GeoEvent Definition. The TrackGap GeoEvent Definition is the other GeoEvent Definition that is defined out-of-the-box. If you click to examine this GeoEvent Definition you will see that its owner is com.esri.ges.processor/TrackGapDetector/xxxx. These owner strings tell you which out-of-the-box processor created the GeoEvent Definitions; the xxxx identifies the GeoEvent Extension release. Sometimes a processor will modify an event’s structure or schema by either adding or removing a field. When a processor does this, it will create a new GeoEvent Definition. The Field Calculator Processor is a good example; you can configure this processor to place its calculated value into a new field. The Field Enricher Processor is another example; it is taking data from a feature service's table and adding new fields to the event it is processing. When a processor creates a GeoEvent Definition for you, you are typically required to enter the name the processor should use for the GeoEvent Definition it will create. It can be important to understand when a processor creates what I have referred to as a managed GeoEvent Definition. A processor will not create a managed GeoEvent Definition until it actually receives a GeoEvent. You have probably discovered that you cannot, for example, configure a Field Mapper Processor which follows a Field Enricher until the Field Enricher has received and processed an event. Once the Field Enricher receives a GeoEvent, it will process the event and create the necessary GeoEvent Definition. Only then can you edit your GeoEvent Service to configure your Field Mapper. Since processors own the GeoEvent Definitions they create, any change you make to the GeoEvent Service which incorporates the processor will trigger the processor to delete its managed GeoEvent Definition when you publish the GeoEvent Service to save your changes. For this reason, you should be aware of when GeoEvent Definitions are created, when they are deleted, and when they are available for reference by another processor or output connector. A few recommendations to take away from this quick discussion: Every GeoEvent has an associated GeoEvent Definition. You should become familiar with when GeoEvent Definitions are created, which components create them, and why. Don’t leave an input connector configured to create GeoEvent Definitions for you. When configuring an input connector to create a GeoEvent Definition, it is a recommended best practice to copy the GeoEvent Definition generated by the input connector’s adapter and then reconfigure your input to use the copy of the GeoEvent Definition. Processors can create GeoEvent Definitions. The GeoEvent Definition associated with an event received by a processor is not necessarily going to be the GeoEvent Definition associated with the GeoEvent which comes out of a processor. Always use a Field Mapper Processor to prepare a GeoEvent’s schema to match a feature service’s feature layer when adding/updating features. You might think you understand the structure of an event you are sending to an output – but it is a best practice to use a Field Mapper and make the schema mapping explicit. Processors may delete GeoEvent Definitions they created. If you configured a Field Mapper “downstream” from a Field Calculator or Field Enricher, for example, the “upstream” processor may delete a GeoEvent Definition referenced by the Field Mapper. As long as you do not double-click to edit the Field Mapper’s configuration you can trust the processor “upstream” will re-create the GeoEvent Definition referenced by the Field Mapper as event data is received by the processor, before GeoEvents are received by the Field Mapper. When publishing a stream service, never refer to a GeoEvent Definition which has been generated for you by an input connector’s adapter or a GeoEvent Definition created for you by a processor. Make a copy of any such GeoEvent Definition(s) and publish the stream service to reference a GeoEvent Definition which you own.
... View more
06-05-2015
12:36 PM
|
7
|
5
|
9714
|
|
POST
|
Hey Katie - To answer your question, yes, several processors can (and do) generate GeoEvent Definitions - if they modify the schema / structure of the GeoEvent they receive by either adding or removing fields. Usually you specify the name a processor should use for the GeoEvent Definition it creates as part of the processor's configuration. This behavior hasn't changed between versions 10.2.2 and 10.3.x of the product. One thing that did change at 10.3 was that you are no longer allowed to edit a GeoEvent Definition owned by an out-of-the-box processor. You can click to view the event definition, but any changes you make cannot be saved. Understanding GeoEvent Definitions is pretty important. Comments I was entering here began to look like their own topic - so I'm going to relocate them over to a blog. Here's a link: Understanding GeoEvent Definitions - RJ
... View more
06-05-2015
11:11 AM
|
1
|
2
|
1531
|
|
POST
|
Hello Sharon - I have not encountered the message java.io.IOException: closedOut you observed. But I have seen messages referring to an event message's size being larger than 10240 characters, my Stream Service output entering an ERROR state, and eventually restarting. Usually when messages constructed from my event data are too large I see messages like: Cannot send a message to the Stream Service connection is already closed due to connection error Text message too large > 10240 chars The WebSocket protocol is the communication standard underlying Stream Services. The 10.3.0 / 10.3.1 release of the GeoEvent Manager exposes a couple of properties you can use to configure the buffer size allocated to hold data being transmitted via the web socket and the maximum allowable size of a text message. Use GeoEvent Manager to navigate to the Site > Settings > Configure Global Settings page Scroll or search to locate the Stream Service Settings: Edit the 'Maximum web socket text message size (bytes)' and the 'WebSocket buffer size (bytes)' properties. Start by increasing the values by a factor of 10x (from 10240 to 102400). You will want to keep an eye on your system resources to verify that increasing this limit is not burdening the JVM (Java virtual machine) GeoEvent is using. It is my understanding that specifying a 102400 byte setting will allocate up to 100k for web socket messages. I’m not sure how frequently the allocated memory is released. If you were to increase the allocation default 100x (from 10240 to 1024000) you could potentially be reserving a full megabyte of the JVM's RAM allocation just for Stream Services use. You can always subscribe to the Stream Service's REST endpoint (e.g. https://your-server:6443/arcgis/rest/services/your-service-name/StreamServer/subscribe) to see the messages being broadcast by you Stream Service to clients. This might help you get an idea of what your expected message size should be, so you know how to set the message size and buffer size property values. You should not need to restart the GeoEvent Extension after editing the properties illustrated above. But you will need to close and reestablish any client connections so that those connections are aware of the changes. If you have clients subscribed to the Stream Service, simply unsubscribe and resubscribe. If your GeoEvent Stream Service output is running, stop it and then restart it. Hope this information helps - RJ
... View more
06-05-2015
10:38 AM
|
2
|
1
|
1214
|
|
POST
|
There is no 'batch delete' available for GeoEvent Definitions ... To be clear, there is no 'batch delete' available in the 10.3.0 release of GeoEvent. Enhancements to the GeoEvent Manager introduced in the 10.3.1 release do allow users to select and delete multiple GeoEvent Definitions. - RJ
... View more
06-05-2015
08:53 AM
|
0
|
0
|
1531
|
|
POST
|
Hello Felix - There is no 'batch delete' available for GeoEvent Definitions. You have a couple of options, however. Reset your product's configuration, then selectively import what you actually want back from an XML you previously exported. Export and edit an XML to remove the GeoEvent Definitions you do not want, the import the entire configuration, then import the your edited XML. Before doing either of these you will want to first export your existing GeoEvent product's configuration so that you can recover work that you have done up to this point. In the GEx Manger Navigate to Site > GeoEvent > Configuration Store Click 'Export Configuration' and save the XML file to a system folder (Option 1) Click 'Reset Configuration' and confirm that you want to delete all components Click 'Import Configuration', choose your exported XML, and then select the 'Selective Import' option Choose just the items you want to import. This might bring the GeoEvent Definitions back, since a GeoEvent Service which recently referred to a GeoEvent Definition might think that event definition is needed and will load it from the XML file for you. If that's the case, then "Option 2" is really your only option. (Option 2) In your favorite XML editor (I like XML Notepad 2007, but Notepad ++ works also) edit the XML file you exported to remove all content between the <geoEventDefinitions> and </geoEventDefinitions> tags. Back in GeoEvent Manager, click 'Import Configuration' and choose your edited XML. Select the 'Import Configuration' option (the default) and import the entire contents of your edited XML. The nice thing about XML Notepad is that it helps validate your edits, allowing you to select and delete icons which appear as sub-folders from beneath a geoEventDefinitions folder, so that you're less likely to produce an invalid XML file. Hope this information helps - RJ
... View more
06-04-2015
06:42 PM
|
0
|
5
|
1531
|
|
POST
|
Hello Adam - My understanding is that finding *.wlock or *.wlock.info files in your ArcGIS Server configuration store is not, in itself, a problem. Likewise finding the erl.exe and epmd.exe processes associated with RabbitMQ running is not a problem. The problem is that the lock files and processes persist after the Windows Service used to run your ArcGIS Server instance has been stopped. Server is using the lock files to indicate to different processes that it is writing to some portion of its configuration ... and it should't be if its Windows Service is not running. I have not observed the lock files periodically go away and come back - that might indicate that Server is trying (and failing) to configure the platform service. Did you try the remedy outlined by Javier above? (My apologies if you did, it wasn't clear to me from your post.) The output you've illustrated from the diagnostic tool suggests to me that if you were to try to status the platform service via its administrative endpoint (refer to notes below my post with the diagnostic tool) you would discover that the platform service either was not configured or could not be started. Sorry, but I think you are going to have to contact Esri Technical Support. The RabbitMQ platform service is configured and instantiated when ArcGIS Server is installed. If the configuration or launch of the platform service fails - GeoEvent will simply not work. - RJ
... View more
06-04-2015
04:34 PM
|
0
|
0
|
910
|
|
POST
|
Hello Ben - Sorry that you're having trouble ... to answer your question, yes, the GeoEvent Extension does support polling secured feeds. I tried configuring an input on my 10.3.1 setup and didn't have any problem ingesting the feed's data, so I setup a 10.2.2 instance to try with the older product release and wasn't able to reproduce the issue you are seeing. I've reached out to Esri Tech Support this morning and spoke with the analyst assigned to your incident. He should be reaching out to you ASAP ... but so far, this looks like a security configuration issue, not a bug. - RJ Mark Holzworth
... View more
06-04-2015
11:01 AM
|
1
|
4
|
4298
|
|
POST
|
Thank you Sabri for the bump ... No, at the current product release (10.3 / 10.3.1), Stream Services are only supported for web maps and custom JavaScript applications developed using the JavaScript API. The ArcGIS Native SDKs (e.g. 'Runtime' SDKs), ArcObject SDKs, and related products (e.g. Desktop, Pro) do not yet have support for Stream Services. Therefore Esri's suite of mobile applications (e.g. Collector, Operations Dashboard) which are dependent on these SDKs do not yet support Stream Services. Support for Stream Services is a priority for the different product teams throughout in the ArcGIS enterprise, but until support is built into the underlying SDKs the various product teams will not be able to support Stream Services in their products. I cannot say to what extent Stream Services will be supported in the 10.4 release as the development and release schedule for 10.4 is still being determined. We will likely have more information for you at the International User Conference in July. Best Regards - RJ
... View more
06-01-2015
03:58 PM
|
2
|
2
|
1586
|
|
BLOG
|
GeoRSS is a standard way of tagging an RSS feed so that applications can use embedded location information in each post. Using the GeoEvent Extension for ArcGIS Server, you can monitor a GeoRSS feed in real time and use it to update the applications and common operational pictures used by your colleagues. Should you encounter a secured GeoRSS feed that you would like to use, there is no standard connector that allows you to pass credentials. However, it is possible to configure a connector (without programming) that will allow you to access a GeoRSS service secured with basic HTTP authentication. You can use the GeoEvent Manager to combine out-of-the-box transports and adapters to configure a custom connector without resorting to the GeoEvent SDK or developing any custom code. An excellent example is available on the Support Services Blog: Configure Your GeoEvent 10.3 Connector to Use a Secure GeoRSS Feed - RJ
... View more
05-26-2015
03:10 PM
|
0
|
1
|
1740
|
|
POST
|
Sharon - I've created a branch for this discussion to place information on a diagnostic utility you can use to check the status of the RabbitMQ platform service in a separate thread. Please check-out my post 'Diagnostic utility for checking the status of the RabbitMQ platform service'. - RJ
... View more
05-22-2015
04:53 PM
|
0
|
0
|
3202
|
|
POST
|
There is an undocumented administration REST endpoint you can reach to check the status of the RabbitMQ platform service. I should emphasize that we did not document this endpoint because its accessibility and interface is subject to change. The RabbitMQ platform service was introduced at 10.3 and GeoEvent is currently the only component using the platform service. This could all change with future releases of ArcGIS for Server - but the information below should be valid for the 10.3 and 10.3.1 product releases. In a browser window, navigate to the ArcGIS Server Administrator Directory and log-in as the primary site administrator. Once you have logged-in, enter the following URL into your browser to navigate to the platform services administrative endpoint: https://my-host:6443/arcgis/admin/system/platformservices/?f=pjson A browser plug-in will make the JSON presented at this endpoint easier to read, but is not required. The JSON you see should contain the fields and values in the following illustration. (For security considerations, the actual id, user, and password files have been obliterated in the illustration.) You should be able to copy/paste the “id” from the platform services endpoint to build a new URL which will take you to the actual platform service: https://my-host:6443/arcgis/admin/system/platformservices/ <id> /status?f=pjson The JSON presented to you from this status query should identify whether or not the platform service is currently configured and on which servers the platform service is running: You can start, stop, and query status using the administrative endpoint above: https://my-host:6443/arcgis/admin/system/platformservices/ <id> /start?f=pjson https://my-host:6443/arcgis/admin/system/platformservices/ <id> /stop?f=pjson https://my-host:6443/arcgis/admin/system/platformservices/ <id> /status?f=pjson
... View more
05-22-2015
04:37 PM
|
4
|
4
|
4755
|
|
POST
|
There is a very basic utility bundled with the Clustering tutorial which will request a status from the RabbitMQ platform service, attempt to connect, and send a message to see if the specified host is able to receive messages. Please download and unzip the attached CheckRabbitMQ.zip to a local folder on the server on which you have installed ArcGIS Server and the GeoEvent Extension. Open a Windows command shell and change directory to the folder containing the files you extracted from the ZIP archive. In your Windows command shell, execute the commands illustrated below: You should see the following usage instructions: Enter the Machine name, Port, Admin user and admin password, separated by a space. (For example: “machine 6080 admin admin_pass): I tend to specify a fully qualified server name and domain (e.g. machine_name.esri.com) - and because my ArcGIS Server is configured to allow HTTPS connections - I specify port 6443. You could also specify localhost and port 6080 if your ArcGIS Server is only configured for HTTP connections. If the utility is able to retrieve a status from the RabbitMQ platform service, connect, and receive a test message, you should see messages like the ones illustrated below: Update March 2017: The diagnostic utility rabbitmqdiag-1.0.jar is throwing a com.esri.arcgis.discovery exception when run against the 10.5 release of ArcGIS Server. Users have reported the same exception being thrown when the utility is run against the 10.4.1 release. The GeoEvent product team does not have the source code for this utility. It was provided as an elementary diagnostic to the GeoEvent team when RabbitMQ was first being integrated. It is not actually part of either the ArcGIS Server product or the GeoEvent Server product and is not being supported. If a new utility can be developed for the 10.5 product release comments will be added to this thread; otherwise please assume that the utility will only work for a 10.3.x product deployment.
... View more
05-22-2015
04:31 PM
|
1
|
8
|
14287
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 02-11-2026 11:38 AM | |
| 1 | 02-11-2026 10:38 AM | |
| 1 | 01-05-2023 11:37 AM | |
| 1 | 02-20-2025 03:50 PM | |
| 1 | 08-31-2015 07:23 PM |
| Online Status |
Offline
|
| Date Last Visited |
02-17-2026
02:45 PM
|