Latest Contributions by DarylHochhalter

Classic Map Viewer loads the tables associated with a mapservice, Map Viewer doesn't, this is a problem IMO! I have to load my layers in Classic and save the map so they are included even when viewed in Map Viewer. Also, there is no way to load them separately from a map service, I'm thinking you can only load tables from portal in Map Viewer.  ... View more

Enterprise Standard base deployment 11.1 on Windows Server 2019. A month or so after upgrade to 11.1 from 11.0 got a notification the server drive was filling up. I found the cause was dump files by Opensearch due to a fatal error involving the JRE installed with portal. I wasn't able to find much online to explain it, so attempted to use windows to repair the portal installation. It didn't seem to change any of the dates on the JRE folder under the portal runtime folder which seemed to have much older modified dates then the rest of the 11.1 install. I had already installed a couple patches including:  Portal for ArcGIS 11.1 Validation and Repair Portal for ArcGIS 11.1 Enterprise Sites Security Patch C   I then installed: Portal for ArcGIS 11.1 Sharing Patch Portal for ArcGIS 11.1 Security 2024 Update 1 Patch One of these did change the modified date for JRE and still waiting to see if this solves the issue. Other then the dump files filling the drive, I haven't noticed anything not working as expected. A portion of the Opensearch log file that goes with the dump: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_IN_PAGE_ERROR (0xc0000006) at pc=0x00007ffdc2f577fb, pid=23168, tid=23896 # # JRE version: OpenJDK Runtime Environment Temurin-11.0.18+10 (11.0.18+10) (build 11.0.18+10) # Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (11.0.18+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64) # Problematic frame: # V [jvm.dll+0x6777fb] # # Core dump will be written. Default location: C:\Program Files\ArcGIS\Portal\framework\runtime\ds\framework\runtime\opensearch\hs_err_pid23168.mdmp # # If you would like to submit a bug report, please visit: # https://github.com/adoptium/adoptium-support/issues # --------------- S U M M A R Y ------------ Command Line: -Dopensearch.networkaddress.cache.ttl=60 -Dopensearch.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dio.netty.allocator.numDirectArenas=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.locale.providers=SPI,COMPAT -Xms2048m -Xmx2048m -XX:+UseG1GC -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30 -Djava.io.tmpdir=K:/arcgisportal/dsdata/temp -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=data -XX:ErrorFile=logs/hs_err_pid%p.log -Dlog4j2.disable.jmx=true -Djava.io.tmpdir=K:/arcgisportal/dsdata/temp -XX:MaxDirectMemorySize=1073741824 -Dopensearch -Dopensearch.path.home=C:\Program Files\ArcGIS\Portal\framework\runtime\ds\framework\runtime\opensearch -Dopensearch.path.conf=K:\arcgisportal\index\config -Dopensearch.distribution.type=zip -Dopensearch.bundled_jdk=false -agentpath:C:\Program Files\Palo Alto Networks\Traps\cyjagent.dll org.opensearch.bootstrap.OpenSearch -d -p C:\Program Files\ArcGIS\Portal\framework\etc\pids\opensearch.pid Host: Intel(R) Xeon(R) Gold 6134 CPU 23G, Windows Server 2019 , 64 bit Build 17763 (10.0.17763.4974) Time: Sun May 12 15:48:23 2024 Mountain Daylight Time elapsed time: 277128.300558 seconds (3d 4h 58m 48s) --------------- T H R E A D --------------- Current thread (0x00000233fe09d800): WatcherThread [stack: 0x00000050afb00000,0x00000050afc00000] [id=23896] Stack: [0x00000050afb00000,0x00000050afc00000], sp=0x00000050afbffab0, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x6777fb] V [jvm.dll+0x72f69f] V [jvm.dll+0x77db5d] V [jvm.dll+0x7a3c9d] V [jvm.dll+0x79c904] V [jvm.dll+0x64e065] C [ucrtbase.dll+0x2268a] C [cyinjct.dll+0x11e7] C [KERNEL32.DLL+0x17ac4] C [ntdll.dll+0x5a4e1] siginfo: EXCEPTION_IN_PAGE_ERROR (0xc0000006), writing address 0x00000233efa439f8       ... View more

After upgrade of ArcGIS Enterprise from 11.0 to 11.1 ArcGIS Pro Python Conda environment version 3.9.16 , I have a task script on the server machine that throws an arcpy ERROR 000732 does not exist or is not supported from either conversion.ExportTable or conversion.TableToGeodatabase. After much troubleshooting, I've determined that these arcpy tools aren't recognizing the odc connection file as a remote database. Instead the Describe object sees them as dataType file. It is the only part of arcpy scripts that isn't functioning as expected and I have many run as tasks. The same ArcGIS Pro Python environment is installed on my desktop computer with Pro 3.1. I can run the very same script successfully from the same location accessing the same .odc connection file. Microsoft ODBC 17 is installed on both machines, the server is windows 2019, the desktop is windows 11. The DNS connection is to a Firebird DB but since arcpy isn't recognizing the file that should point to that DNS, I don't think that matters. The ODBC DNS connects successfully via ODBC data source administrator and I can connect and retrieve rows in a python script using pyodbc. It seems to be just arcpy functions on the server machine that can't connect because they simply don't recognize the .odc connection file that is part of the string to a table and don't even attempt to connect according to the ODBC trace log from data source administrator. Although the ArcGIS Pro Python environment versions are the same on both machines, apparently they aren't the same. I haven't noticed any other functionality issues since the upgrade to 11.1 Is there some configuration file that could fix this? Filesystem extensions associations? What are the differences in the server arcpy environments and the desktop arcpy environment since they do run on a different OS. Barring an easy fix, I'm inclined to find another way to get the info I need from that Firebird database. Perhaps this should be a BUG? ... View more