POST
|
Tiffany, sounds like you had the same experience as myself trying to figure this out. Misery loves company, so thank YOU, I feel better now!
... View more
01-29-2016
09:11 AM
|
0
|
1
|
474
|
POST
|
Sharing some good news this morning. I have not seen an error relating to TCP, network or DBMS since I had our network guy make some changes. What was happening is that when the back up job would run it would freeze the GIS and DBMS servers while it took a snapshot of each server. It would also freeze when the snapshot was reconciled back to one file. It seems as though this state of "freezing" would cause the connection to the SQL server to stop working. It was not a RAM or resource issue after all. Beware anyone out there backing up any of their servers during business hours. I now have it set to run once daily at 11pm, about an hour before the GIS server recycles for the day.
... View more
12-01-2015
07:05 AM
|
2
|
0
|
2906
|
POST
|
Hi David, thanks for your insight on this one. I took your advice and dug into the SQL logs a bit more and did not see anything explicitly showing an error due to RAM or other resource driven error. However, I did notice that there are errors every few hours that begin with Source = spid113 "I/O is frozen on database model...." a second later with Source = backup "Database backed up....." a second later with Source = logon "Error 18456 severity 14 State 11" a second later with source = logon "login failed for user 'domainname\backup'....... Seeing the I/O leads me to the network which the GIS server logs were also hinting towards with the TCP and closed connection reference. I have reached out to my network guru and he has indicated that they are backing up my servers every 2 hours where we decided this may be playing a role. He has since moved the backup job to nightly. I will continue to monitor the server and SQL logs and will re-post with any updates that I have... hopefully that we fixed this error.
... View more
11-24-2015
07:17 AM
|
3
|
2
|
2906
|
POST
|
I'm seeing an error in our Server logs since we have upgraded to v 10.3.1 about 2 months ago. I have not been able to locate a specific time, layer, or service for this error. It seems to happen at random.The error reads as follows, the bold being our enterprise specific names that I substituted. "There is an error during the draw Layername (1.) Failure to access the DBMS server [08S01:[Microsoft][SQL Server Native Client 11,(2.) 0]TCP Provider: An existing connection was forcibly closed by the remote host,(3.) ] [dbname,(4.) DBO,(5.) FeatureName]." We have our enterprise gdb in a SQL environment version 2008r2 the server OS for that server is Windows Server 2008r2 SP1 Our GIS server is on a machine running Windows Server 2008r2 SP1 GIS Server Version 10.3.1 Does this error mean the DBMS and or server has closed the connection with the GIS server? I have found that the GIS server has both NativeClient 10 and 11 installed for what it's worth. Should I have our network guy help me with this, or is it a SQL or ESRI specific problem I am seeing. Hopefully just a simply connection timing setting I can adjust. whatcha thinking out there?!
... View more
11-23-2015
08:31 AM
|
1
|
5
|
8445
|
POST
|
Once we realized we were querying against the base table and not the versioned table all problems solved. SQL novice learning experience. This was helpful, thank you. Make sure you query against the table_VW not the original table you loaded/ created.
... View more
10-02-2015
12:55 PM
|
5
|
0
|
1277
|
POST
|
Dennis, great resource in your link. This worked for us. We moved from LM 10.1 to 10.3.1. We did not de-authorize before the upgrade installation, simply stopped the LM. Once installed, clients other than from the same machine the LM is running on, were unable to locate the LM server. Received the message "<<server name>> does not have a valid license. please enter a vaild license manager server" Nothing changed in our firewall and the same ports were allowed in bound. Using the article that you linked we were able to make the adjustments as shown... and success!! Funky little error but easily fixed using this article.
... View more
08-26-2015
02:50 PM
|
1
|
0
|
5461
|
POST
|
We have a few jobs that utilize our geocoding service. The issue that I am being presented is that sometimes the table that is used as our input includes an address with multiple addresses, that are not intersections. For example, we might see in the input table address field "4700 South Lake Park Avenue, 1350-54 East 47th Place, and 1360-64 E. 47th Place" The way our service is currently working, only the first address in the string is being matched. The way I would like to see this function is for this record to be skipped or returned as un-matched. Any ideas out there on handling this on the geocoding tool/service side? Ideally I would like to leave our input table (a view) as is, but I guess I could always adjust it so that we simply do not include this record in the input table. This behavior exists in the tool and also within the service published from this tool. ideas??
... View more
07-15-2015
10:13 AM
|
0
|
0
|
2139
|
POST
|
We have moved are server site to 10.3.1 after a bug was logged at 10.3 which affected our site. exportwebmap GP failed because we were filtering some radii rings with the SHAPE.STLength() field. BUG-000084700 "Map service query operation fails when StandardizedQueries is enabled and Shape.STLength() is used in a WHERE clause." This bug is fixed in version 10.3.1. We have verified that this bug has been fixed and all is good..... EXCEPT We are now getting a new error when we execute our exportwebmap GP service from our site that Layer "layer1": Unable to connect to map server at......<< Insert service name here>> hap However, the layer that shows in the log differs from service to service. Sometimes layer 1 sometimes layer 2 etc. To test whether or not an actual layer in the DB was causing this failure, we tried removing layers, adding layers, removing basemaps etc. No dice. Which makes sense as we didn't touch the SQL server when upgrading. The Services and web adaptor seem to be working as the web map application will load the data no errors. All services load and function except for printing. THEN I looked at our dev site to see if that was showing the same results on exportwebmap GP. Viola! it works. So what is different? Well, this site does not use our domain (for testing purposes) and the GIS server IP is hard coded using the local hosts file. SO What I did was the same for our test site. Bypass our domain by changing the binding in IIS so that our domain was no longer in the site url and then changed the local host file to bypass the DNS server. Now I can access the testsite without the domain.com added to the url. RESULT Prints fine. no errors, no nothing. Works as expected, rings are filtered with our SHAPE.STLength() field. Anyone have any ideas on why our domain is preventing the GP exportwebmap from connecting to our DB? Is there a new permission or bug we are not aware of at 10.3.1 exportwebmap or GP tools in general? Just can't figure out why once we add the domain to this site this tool fails by way of not connecting to the data. Is this IIS, ESRI, network permission or what?.....Stumped.
... View more
05-29-2015
08:42 AM
|
0
|
0
|
2709
|
POST
|
For what it's worth..... I am in your boat Paul - The errors we were seeing were all over the place and got worse and more frequent over a month or so. Like I said, this all seemed to go away after IT moved our server. I am told that there were no errors on the server, but I think a failing piece of hardware could have very well been the culprit. What they did was move the server our GIS server was on from a SATA drive on the SAN to a new solid state drive on a new SAN. Nothing was ever local, or in a hard box, all on the SAN. I hope I didn't screw that up and it makes sense. Like I said earlier, file this away as who knows....but it works now
... View more
05-26-2015
11:47 AM
|
1
|
0
|
985
|
POST
|
Randy, Joshua - Thank you. I wish I could mark you both as correct. I went back and did more thorough research and realized these fields didn't disappear at all. You guys are spot on. I understand what I am seeing now. I have shared this with the developer and we are all on the same page now. What I don't understand is why the filter is not working. When we send the JSON exportwebmap parameters without the Shape.STLength() in the definition expression the print works. Include this and we get our failure. All values check out in arcmap too.... I'm hoping the developer digging through the code a bit more will reveal the problem. But I think that's for a new thread. Cheers,
... View more
05-15-2015
12:02 PM
|
1
|
1
|
1998
|
POST
|
Hi Randy, Once I read this, I was sure it was the case, but after reviewing the storage settings I no longer think this. The database was upgraded by way of Right Click on DB in catalog > General tab > Upgrade Geodatabase under the upgrade status area at the bottom. Storage: High Precision using Geometry spatial type (SRID 102008)
... View more
05-14-2015
09:49 AM
|
0
|
1
|
1998
|
POST
|
Yet another snag in our migration from 10.1 SP1 to 10.3. We have upgraded our Server, web adaptor, desktop and geodatabase to 10.3 and all seems to be working as expected, except that our print command from our customized server site stopped working. By stop working I mean it was no longer filtering buffers that were beyond a certain radius. our exportwebmap GP takes the point and associated buffers and prints them to a pdf but eliminates all radii that exceed 1/2 mile using the Shape.STLength field. In our config.js file "PrintMapBufferLenghtLimit: 5060, //in meters, this is just over the circumference of the 0.5 mile ring" So all the radii rings were being printed and we started digging. Looking at the buffer feature in our SQL enterprise GDB via Catalog, this field is VISIBLE and the buffers all draw and respond appropriately, so clearly it's there. Looking at the buffer feature in our SQL enterprise GDB via SSMS, this field is NOT VISIBLE, which is most likely why our code is not able to filter properly. Within SSMS if you expand the table and expand columns, it is missing, along with the Shape.STArea() field.....wtf? EDIT: All polygon features in our database are missing these two fields in SSMS. Any idea out there? How do we get these fields back into SSMS and why did they go missing in SSMS but not catalog or desktop?
... View more
05-13-2015
06:19 AM
|
0
|
6
|
6991
|
POST
|
This is great insight Domenico. Unfortunately, I am not going to get a chance to run through this option, but I'm most certainly going to keep this as the next option. The brain trust has decided that it's best to wait until we move our production env. to 10.3 and see if we still see these errors and go from there. So, speaking of errors.... The errors that I have posted here about are no longer occurring, which is why we are going to wait. It's been a solid week now, and the system as a whole has been incredibly stable. The week after my last post up until last Thursday, there were all sorts of new errors in the server logs mostly involving layer1: Cannot connect to this server. ExportWebMapForMapViewer.GPServer Failed to construct instance of service 'Figure1.MapServer'. 76579468-886e-41a8-b9af-f8d3f126c332 Server From the event logs the last error that we see from last week is -Faulting application name: ArcSOC.exe, version: 10.1.1.3143 -Faulting application name: javaw.exe, version: 7.0.50.5 So, what changed: Well, the first thing we did was remove the layer groups that were associated with two of our services. The group feature is not allowed when publishing, but once published it would still and work normally. Figured it was best practice to remove all errors that we could Stopped a service completely. One of our services was not being refreshed each night when the server would recycle services. There were errors on the server logs and this service would just not publish, but also did not have any errors directly relate to the service. This is still not running. IT has moved all of our application web servers to new SAN storage. They spent a few weeks tinkering and moving web server. The use of the SAN should have prevent edany moves from affecting our systems, but I'm not 100% sure this is true. It seems that once all web servers were moved, ALL errors stopped in the event logs. The GIS server was rebooted about 6 times over a week + File this away as who knows....but it works now.
... View more
05-12-2015
05:59 AM
|
1
|
2
|
985
|
POST
|
For anyone following, We gave our ArcGISWebAdaptorAppPool a recycle at 2:30pm yesterday. We also see our tandem of errors at 12:18:01 AM and 12:19:08 AM this morning respectively. So, recycling did not make these errors go away for any length of time. Seemed to have no effect. I'm going to try the same thing same time today and see if we can get our errors to show at the same time tomorrow, trying to see if there is a correlation between the AGS recycling services at midnight and our web adaptor errors.
... View more
04-29-2015
07:26 AM
|
1
|
4
|
985
|
POST
|
Rebecca - thanks for the suggestion, but no, none of the accounts have changed in 2+ years since we went to 10.1 Patrick - I'm going to try that and see if anything changes. We see these errors every 24 - 48 hours so it may be a few days before I have any results. The default recycling for the webadaptorapppool is set at 1740 minutes (29 hours). However the error events do not coincide with the default recycling.....wishful thinking. I wonder what ESRI recommends if anything for app pool recycling timings? Thank you for your tip, will be in touch.
... View more
04-28-2015
11:30 AM
|
0
|
5
|
985
|
Title | Kudos | Posted |
---|---|---|
1 | 03-03-2023 08:14 AM | |
1 | 05-07-2019 08:32 AM | |
1 | 12-04-2013 06:08 AM | |
1 | 08-31-2023 08:19 AM | |
1 | 07-21-2023 06:08 AM |
Online Status |
Offline
|
Date Last Visited |
09-09-2024
09:02 PM
|