nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ArcGIS Server 10.1 - Tomcat issues

RobertJones2

Preparing a deployment of ArcGIS Server 10.1 has led me to a number of questions around security as regards the embedded Tomcat that ships with it:

1. Is this embedded Tomcat recommended for deployment in production environments? I note that the embedded Tomcat for Server Java at 10 was not, which makes me suspicious whether this is also the case for Server 10.1:

'By default, the services you create and deploy in ArcGIS Server Manager are available through Manager's internal Web server. This, however, is not a recommended production environment. By exporting the REST handler into a standard .war file, you can deploy this as an application to an ESRI-supported J2EE server.'

http://help.arcgis.com/en/arcgisserver/10.0/help/arcgis_server_java_help/index.html#/Exporting_the_REST_handler/00920000009p000000/

2. What is Esri's policy as regards patching this embedded Tomcat if/when vulnerabilities in Tomcat or the bundled JRE come to light?

3. Assuming Esri do not intend to produce a fresh release of Server with each patch to Tomcat/Java, what resources are provided to enable us to patch the embedded Tomcat/JRE ourselves? Is this thought so trivial as to not warrant documentation?

I've had a good look around, I think, but this information doesn't seem to be available.

Najděte více příspěvků označených jako

Accepted answers

All comments

RobertJones2

Ok, so I've managed to answer question 1:

http://blogs.esri.com/esri/supportcenter/2012/05/29/welcome-arcgis-10-1-beta-%E2%80%93-a-few-tips-for-arcgis-server-migration/

'At 10.1, there�??s only one �??Flavor�??. Similar to ArcGIS Server Java edition, ArcGIS Server 10.1 ships with an application and web server. At 10.1, these internal servers production ready'

I'd suggest adding a comment along these lines to the proper help files.

Still interested in any answers to questions 2 and 3

RobertJones2

I now see that AGS's internal web server is in fact Apache Geronimo, which is built on top of Apache Tomcat (and other components).

Still no documentation on Geronimo and 10.1 anywhere that I can find, and still interested in 2 and 3 as they apply to Geronimo, if anyone Esri or otherwise can advise.

RobertJones2

(Tumbleweed rolls across the playa. Somewhere distant a bell tolls, mournfully.)

IsmaelChivite

Hi,

thanks for posting your question. I hope the following information helps:

1. Is this embedded Tomcat recommended for deployment in production environments? I note that the embedded Tomcat for Server Java at 10 was not, which makes me suspicious whether this is also the case for Server 10.1:

We include a wide collection of third party components within ArcGIS Server, and Esri ensures that they are internally used by the software in a manner that will allow you to use ArcGIS Server in a production environment. Unless specified by the documentation, these third party components are production ready for the purpose of use within ArcGIS Server.

2. What is Esri's policy as regards patching this embedded Tomcat if/when vulnerabilities in Tomcat or the bundled JRE come to light?

Esri diligently looks at security vulnerabilities in third party components used by ArcGIS and releases security patches when appropriate. It is important to note that security vulnerability alerts in third party components do not necessarily translate into security vulnerabilities in ArcGIS software. It is not recommended that users modify internal components used by ArcGIS for the purpose of addressing security vulnerabilities, unless specified otherwise in the documentation.

3. Assuming Esri do not intend to produce a fresh release of Server with each patch to Tomcat/Java, what resources are provided to enable us to patch the embedded Tomcat/JRE ourselves? Is this thought so trivial as to not warrant documentation?

We have not documented many of the third party components used by ArcGIS Server on purpose. Unless specified by the documentation of the software, third party components of ArcGIS Server should not be modified or configured. Manipulating these third party components, or any internal components of ArcGIS Server on your own will in infringe the Terms of Use of the software and in practice eliminate any chance that Esri will be able to help you through Technical Support.

If you want further details or clarification, please do not hesitate contacting me directly.

Thanks,

Ismael Chivite
Senior Product Manager. ArcGIS for Server
ichivite@esri.com

RobertJones2

Many thanks Ismael.

RakeshRay

Does anyone knows how to enable Tomcat logs?
Out of 4 arcgis servers that I have, tomcat dies on two of them underload and I need to go bottom of it.
I am using 10.1 SP1 on windows 2008 sp2.

KirkMower

It is also apt the they use Geronimo because this is what one would properly yell when jumping off a cliff...and I agree with Robert that lack of documentation still leaves us on a wing and prayer. Just because 'It has always been thus...' doesn't mean it needs to continue...However, Robert, rest assured that as long as ArcGIS Server remains the black art that it is, you will have job security. GO ESRI.

RichardWatson

I think that Ismael made it clear that ESRI considers all of this to be internal and has no plans to document it. I can certainly understand this position.

The counter argument to this is that sometimes you have to debug complex problems which requires an understanding of the internal components. I have already debugged ArcGIS Server 10.1 problems which required these type of skills.

Why not just file an issue with ESRI support? The problem there is that ESRI support requires a simple reproducible test case before they file an issue. Coming up with that can sometimes be onerous. This point should be clear when you look at some of forum posts with regards to crashes that have a very high number of posts. If a thread has say more than 50 posts associated with it from numerous users then it is a pretty good sign that there is a problem.

Suggestion - ESRI should adopt a voting scheme for addressing these type of issues similar to what happens for new features. Let us mark a post with the a count/flag that ESRI needs to investigate this issue and report back the results to the user base.

So... that leaves you with the challenge of figuring out the internal components yourself. If you don't know the Java technology stack then you need to start learning it.

AndrewBrown

Ahh, but that'$ where Profe$$ional $ervice$ come$ in....

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.