I have done several viewers for a client of ours using the ArcGIS Javascript api. Point is, this server has been in use for several months now with no problems at all. Its a decent, dual quad core box, and has been handling the load quite nicely. Then came the release of our 'Historical Flight Tracker. Its a site geared towards the the aviation industry. It allows pilots to see where they have flown in the past 30 days. Its a neat little app that has lots of cool asynchronous database calls using coldfusion (cfajaxproxy). Thats another blog post if anyone is interested...

Anyway, shortly after release, we noticed that the lsass.exe (in task manager) process was starting to eat lots and lots of memory and the cpu was ranging upwards of 30-40% at times. Eventually, the entire server would be become totally unresponsive and needed a hard reset. Well, if I was smart, I would have searched the ESRI support center first, but I didnt. I hit the Google and tried every 'fix' for 'high cpu lsass.exe' I could find. Well, after no luck, I finally took a look at the ESRI support site, and it turns out that this is a known issue for ArcGIS Server sites that are under a heavy load, which this one certainly is. Its on the front page (on the right side of the page) FltPLan.com, which is one of the top destinations for the aviation industry.

So, if you have a site that is under heavy load, and you notice the lsass.exe processes getting a little carried away with itself, be sure to have a look at this Tech Article from esri. The long and short of the issue is this:

"Every time a Web service or application that uses impersonation handles a request, the underlying ASP.NET worker process must use the Local Security Authority Subsystem Service process (lsass.exe) to authenticate. Under normal load conditions, this authentication operation is insignificant.

When a Web service or application that is impersonating is under heavy load (more than 25 simultaneous connections per second) for extended periods of time, the per request authentication operations begin to severely affect the memory and processing footprint of the lsass.exe process."

A reader recently sent us a email wondering about printing with the ArcGIS Server Javascript api. It was a great question that I'm sure others have, so I thought we would share our response to her.

Gabi writes:

I was trying to print a map from your page

http://maps.roktech.net/GoMaps93/

I can’t get the map to print. I was wondering if you were aware of that problem?!

We have just published our ArcGIS Server Javascript API for the residential election and we have a similar problem not able to print the map – on some printers!

I have tested 18 different printers and 12 printed the map ok but 6 did not.

I’m just checking on this print issue with you to see what kind of problems you have experienced if any at all!

This would be a forum ESRI link with discussion about printing from an ArcGIS Server Javascript API.

http://forums.esri.com/Thread.asp?c=158&f=2396&t=266413&mc=5#msgid822082

Thank you

Trent, our lead ArcGIS Server developer responds:

Gabriela,

We have had problems printing with the Javascript API as well. To start, you can not pass user drawn graphics to a print page. This pretty much eliminates the drawing tools for us. If our users can draw on a map, they are going to want to print their graphics with the map. Another issue is with IE. Internet explorer will only print the first two graphics layers. If you print from firefox you will get everything. This may be the issue you ran into with the different printers. It may not have been the printer, but the browser.

One solution around the drawing graphics is to reformat the main page for printing. Basically, you would hide or reposition your page elements by using div tags. You would also need to resize the map, so it fit on one print page. This can all be done dyanmically without having to open up a new window or print page. After the user prints the page, you can return all of the page elements to normal. Once again, in IE you will only get the graphics and the 1st layer.

One work around for the IE printing issue is to use a server side programming language to mass each of your layers together into 1 image. The server side code would make image request to each layer individually. Then, the server side code would take those images and merge them together. The resulting image would be passed back to the print page as 1 image. Consequently, you would see all of the layers when printing from IE. Once again, you are still limited from printing user drawn graphics.

I'm not sure if this helped you at all, but I would be more than happy to help if you are having a specific problem. Although our printing is not where we would like it to be, we have been able to print maps by passing query paramaters to a print page.

Here is an example of one of our print pages. It may be a little slow loading, as we are building cache on that server. After the page loads completely, displaying the parcel graphic and the parcel attributes, the browser's print dialog will come up.

http://beta.roktech.net/Flagler93/print.htm?pid=07-11-31-7024-00520-0040&XMin=-81.2210496187643&YMin=29.525174008735704&XMax=-81.2197409152355&YMax=29.526482712264496&h=600&v=4

Thanks,

Trent

We have a new site that we would like to share with everyone. Its targeted towards the public for county/city governments. Its a work in progress of course, but we are well on our way with it. It was also recently showcased by ESRI on their Live User Sites showcase page.

There are several interesting technical details going on with the site that Trent will touch on in a upcoming blog post. However, I'll give you a brief overview now:

-Its built with the new 9.3 Javascript api
-Initially, we attempted to perform parcel attribute searches such as parcel number and owner name via the Javascript API QueryTask. Although, turning off the geometry in the query parameters improved performance, we found that using Coldfusion to query the database directly was much faster.
-Its also using our new Map Cache Hosting service to serve up the 'Flagler Aerials' layer.

Google has released an amazingly simple find-my-polling-place tool. Of course, as you would expect, its all map centric. I just love seeing GIS and maps penetrate our everyday life.

We have started moving our ArcIMS websites over to the JavaScript API. The ArcGIS Javascript API has shown fast performance and is very easy to customize. After setting up cache for your ArcGIS Server services, you can put out some really fast maps. Consequently, we were excited about the opportunity to get to work directly with the development team during Holistic testing on the new version.

Overall, I was very happy with my experience in Redlands. It was great to see some of the new features coming out at v1.2, but more importantly it was nice to bounce ideas off of fellow developers. The ESRI Javascript API development team has done a great job of adding in some key functionality that will eliminate some work-arounds in our current websites.

During the testing, we implemented the new features into some of our own workflows and tried to find bugs. However, a majority of our time was spent working with the dojo framework and creating custom dijits. For those of you that are new to the Javascript API, it is built on the dojo framework. The framework is full of easy to implement user controls that will add a professional look to your website. More information and documentation can be found at http://dojotoolkit.org/book/dojo-book-1-0

In addition to the existing user controls on that website, you can also create your own user controls or dijits. After creating a dijit, it can be added to your site with a simple 1 line div tag. For example, you can create an overview map dijit or a table of contents dijit. No, these items will not be packaged into the next version, but maybe we will seem them up on the Code Gallery soon. One thing to keep in mind is that the Javascript API is not a replacement for the WebADF. The Javascript API should be used to create simple websites that need little instructions for their users. It should be targeted at users that are used to a Google Maps type interface.

There were browser based issues that came up in the testing. Most of them were errors with the way IE handles graphics… if only we could tell all of our users to use firefox. One important issue that still exists is printing in IE. Only the top two layers will print. Since one of the layers will be your graphics layer, you can only have 1 more data layer print with your map.