We are not running into any heap errors that I can see; no occurences of java.lang.OutOfMemoryError in stdout/stderr.
When I do find a reason for the issues I will be sure to share my findings. On Wed, Jul 28, 2010 at 12:54 PM, Lyle Taylor <[email protected]> wrote: > ** > > What caused you to pull patch 5? > > > > 400 users seems like a lot to support on a single MT. Are you perhaps > running into JVM heap limits? > > > > Lyle > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Wednesday, July 28, 2010 11:48 AM > > *To:* [email protected] > *Subject:* Re: Session Invalid Error > > > > ** Patch 5 was pulled. I have not considered patch 6 since the release > notes did not indicate any fixes in the area where I have problems. > > > > We have Apache in front of Tomcat because we have some Apache modules that > we need to use to provide certain services. > > > > Our problems don't seem to come into the picture until we have ~400 > concurrent users on one mid-tier server. Low volume against the server does > not reproduce the issues. > > On Wed, Jul 28, 2010 at 12:41 PM, Lyle Taylor <[email protected]> > wrote: > > ** > > Hmm. Odd. I was seeing something similar at one point, but I think I > tracked it down in our case to either the F5 or the IBM HTTP server > switching someone from one MT server to the other for some unknown reason. > It hasn’t happened for a while for us, though, so I’m not sure what > changed. I’m pretty sure I’ve never seen sessions expire like that so long > as the person stays on the same MT server, though, on 7.1 p5 or 7.5 p3. > > > > Just out of curiosity, why do you have apache web servers in front of > tomcat if they’re simply forwarding to the local tomcat instance? Are you > serving up static content (e.g., documentation) as well? > > > > Now you’re making me nervous about upgrading. We’re currently on MT 7.5 > p3, and I was considering changing to p6. Have you done any testing with p5 > or p6 yet to see if that makes a difference? > > > > Thanks, > Lyle > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Wednesday, July 28, 2010 11:27 AM > > > *To:* [email protected] > *Subject:* Re: Session Invalid Error > > > > ** I've verified this is not the case by looking through the Apache access > logs. The sessions are staying with the same Apache HTTP server. The > Apache HTTP servers talk to Apache Tomcat on localhost, so the HTTP servers > aren't redirecting to different Tomcats. > > On Wed, Jul 28, 2010 at 12:15 PM, Lyle Taylor <[email protected]> > wrote: > > ** > > I would try to double-check that when this happens, the person hasn’t > actually been switched from one mid-tier server to the other – doing that > could cause what you are seeing. You could verify this by logging into the > configuration page and looking at the cache information just after someone > gets an invalid session message and has to log in again. There are entries > on the cache settings page for everyone that has recently logged into the > mid-tier on that server. If you find an entry for that person on both > servers, then I would suspect that something is causing the F5 to switch > from one server to the other, despite the sticky bit setting. > > > > Lyle > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Wednesday, July 28, 2010 8:10 AM > *To:* [email protected] > *Subject:* Re: Session Invalid Error > > > > ** We are facing the same issue with mid-tier 7.5 patch 4 on Tomcat 6.0.20. > > > > Axton Grams > > > > The opinions, statements, and/or suggested courses of action expressed in > this E-mail do not necessarily reflect those of BMC Software, Inc. My > voluntary participation in this forum is not intended to convey a role as a > spokesperson, liaison or public relations representative for BMC Software, > Inc. > > > > On Wed, Jul 28, 2010 at 2:50 AM, Aluru, Radhika <[email protected]> > wrote: > > ** > > Hi Listers, > > In my Test environment, Session timeout is set to 60 minutes in Remedy > midtier servers. I have F5 load balancer in front of two midtier servers and > sticky bit is set to 120 minutes on the F5 load balancer. Application > timeout is set to 1 hour. When users are accessing the application via web, > users are getting session invalid or timed out error before 60 minutes > sometimes before 20 minutes . This is not happening every time. It is > intermittent. Has anyone faced this type of issue and found any solution to > resolve this? > > I have tried setting the session time out in web.xml(located in > D:\ARSystem\Mid-Tier\WEB-INF) file of the midtier servers. But this didn’t > resolve the issue. > > Any help would be appreciated. Thanks. > > Environment Details: > > AR Server --7.1 patch 3 > Miditer --7.1 patch 6 > OS --Windows standard 2000 > Database -- SQL 2005 > > Regards, > > Radhika Aluru | Remedy Admin | Direct Line: +1 713 214 8270 | Mobile: > 00919177708021 > > **************************************************************** > > Confidentiality Note: The information contained in this message, and any > attachments, may contain confidential and/or privileged material. It is > intended solely for the person(s) or entity to which it is addressed. Any > review, retransmission, dissemination, or taking of any action in > > reliance upon this information by persons or entities other than the intended > recipient(s) is prohibited. If you received this in error, please contact > the sender and delete the material from any computer. > > > > > > **************************************************************** > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > > NOTICE: This email message is for the sole use of the intended recipient(s) > and may contain confidential and privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy all > copies of the original message. > > > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
