I recall the silent install within RKM defaulting to C:\Program files, but after years of watching Windows updates grow and grow until the C: drive fills up (on machines built like yours), I have been building my new web servers with one big C: drive, period, so that isn't an issue for me now. If it were, I would install Tomcat first from some other source - in the path I required, then make sure it was the only Tomcat instance running when I ran the RKM installer. No, RKM and mid-tier cannot share the same port, because the second instance will not even start on 8080 if another is already running there. Since you are going to set all active link references to RKM manually, you can use whatever port you want. The only downside to running two (or more) instances of Tomcat on the same server is that only ONE gets to use the little Configure Tomcat applet to manage it, normally the first one installed. My understanding is that it is just a wrapper on the first instance of Tomcat installed; the rest have to be managed simply as Windows services as long as they are installed that way. You have to set the memory allocations directly in the registry for the other instances without the "assistance" of the Apache Tomcat Properties dialog box. Since you are providing separate memory allocations to the Tomcat instances under mid-tier and RKM, there is no competing for resources if the box has enough RAM. I had been giving each instance between 512 or 1024 and 1536, but have scaled back to 512 and 1024 on the current test mid-tier based upon the latest performance tuning guide for BSM. I don't remember seeing mid-tier use more than 6 or 700 mb anyway (during a prefetch of multiple applications - no longer supported in 7.1). It might if I had dozens of simultaneous users, but we will run out of licenses first. Usually it is running closer to 400-500 mb of RAM for mid-tier; RKM is at only at about 80 mb.
Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Watson, Benjamin A. Sent: Monday, October 22, 2007 3:02 PM To: arslist@ARSLIST.ORG Subject: Re: Help with redirection which does not break RKM ** Thanks for the suggestion Chris. I'd thought about running separate Tomcat instances, one for each application, but have never done anything like that before. Any gotchas to maintaining separate instances? What's all involved to set them up initially, just running the RKM and MidTier installers? Further, I did notice that RKM bundles Tomcat 5.5.20 whilst MidTier uses 5.5.17. My preference has been to install MidTier first, then RKM. So when it comes to installing RKM, I tell it to use Tomcat but not to install it and that I'll setup everything "manually". I did perform a setup once under the guidance of Darren Twede with KMXperts/BMC where, when attempting to solve the image/attachment issue only and not knowing about the redirection bug, he told me to install RKM first, and then the MidTier. The only thing about this that left a bad taste in my mouth was that the RKM installer does a silent Tomcat install and does not let you choose where it'll be located (e.g. it forces C:\Program Files\). Has this been your experience as well? We typically have a small C: partition as just the OS and create a large D: partition for all applications. I do have a virtual machine I can play with though, so I'm open to the dual Tomcat instance scenario you mentioned. Do you notice any performance improvements/penalties running two Tomcat instances for MidTier/RKM versus a single instance? How do you get both instances to listen on the same port? Ben _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Monday, October 22, 2007 2:51 PM To: arslist@ARSLIST.ORG Subject: Re: Help with redirection which does not break RKM My assumption is that you are running mid-tier and RKM on the same Tomcat instance. I have had much better luck running them on their own instances of Tomcat - mid-tier installs 5.5.17 and RKM installs 5.5.20 when you tell them to install their own bundled copy. The primary reason I did this was to prevent RKM / Hummingbird errors from restarting the Tomcat instance that mid-tier depended upon, triggering a new prefetch. Then you would be able to set a redirect for the mid-tier Tomcat and it would not affect the RKM Tomcat. For the pre-production lash up I went even farther, moving RKM to its own box with AIE; there is still a second Tomcat instance on the mid-tier box, but that is for the Kinetic Request web. Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Watson, Benjamin A. Sent: Monday, October 22, 2007 2:18 PM To: arslist@ARSLIST.ORG Subject: Help with redirection which does not break RKM ** Listers, I've identified that performing a redirection in Tomcat breaks a specific Remedy Knowledge Management function. We have a requirement to allow an end user to enter the following: https://<servername> as a URL and be redirected to https://<servername>/arsys/home. This is more or less a convenience requirement. I've done this under IIS before with no issues. We've since moved to MidTier 7.1 under Tomcat standalone and I've performed the above by modifying index.html under Tomcat\webapps\ROOT as follows: <html> <head> <meta http-equiv="refresh" content="0;URL=https://<servername>arsys/home"> </head> <body> </body> </html> This too has the desired result as the end user can simply enter https://<servername> and get to the Remedy login page without issue. The issue by doing this is that it breaks RKM's ability to embed images or attach files to documents. I used the Fiddler application to trace what was going on after setting Tomcat back to regular non-SSL HTTP and saw HTTP 302 errors being thrown when attempting to perform the attachment or image insertion functions. HTTP 302 means that the server is redirecting the user somewhere else to get the content. From an end user's perspective, all is well until they attempt to attach a file or insert an image. Upon performing either of these functions, they simply don't work. When attempting to attach a file, "nothing happens". When attempting to insert an image, a "red X" is displayed. This is something you might encounter on a site with a broken URL to an image. After getting nowhere with BMC support on this, some Google'ing revealed the following: "If myapp is a directory (not a web application), Tomcat will send a 302 Error to redirect your browser to http://localhost:8080/myapp/index.jsp. This is completely invisible to the user, so everything looks fine. The problem really occurs if your JSP handles username/password authentication i.e. http://username:[EMAIL PROTECTED]:8080/myapp What happens is that Tomcat will send a 302 to redirect the browser to http://localhost:8080/myapp/index.jsp ... which the browser delightfully does, but upon redirection, the browser doesn't associate the "username:password" portion with the new URL (possibly due to security issues). So if your index.jsp is handling the authenticate protocol, the browser will pop up a diaglog prompting the user for username/password instead of just logging in as it should." So, when the user attempts to embed an image or add an attachment to an RKM article, their credentials are being stripped and you can see references to an AccessDenied servlet in the Tomcat logs. Therefore, the attempt to attach a file or insert an image silently fails. My question is this: Is there a method to perform the desired redirection that won't effect RKM in the manner described above? I've resorted to abandoning the redirection and, after clearing the cache and restarting Tomcat, the issue goes away. When reinstating the redirection method above, the issue returns. Any ideas? Ben __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
