This does remind me of an issue one of our departments had which was caused by their firewall timeout. In that case, it was fairly obvious because they recognized that their problems started around the time their firewall was activated.
The solution we used for them was to have the Remedy Home Page (which was the form they were most concerned about) automatically refresh with an active link On Interval action timed to be somewhere under their firewall's timeout limit. Upon loading the Home Page, a hidden field is set to indicate whether they are a fixed or floating license user. Then the On Interval refresh is only done for the fixed users so the floating licenses aren't tied up. David Durling University of Georgia > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of remedymarv > Sent: Wednesday, June 29, 2011 1:30 AM > To: arslist@ARSLIST.ORG > Subject: Re: Remedy User Tool has 20 second delay after a period of > inactivity > 40 minutes > > Update. We have been working on this problem continuously since this post. > Remedy Support has not come up with anything despite asking for many > logs. > On the production server, we've switched from having no assigned ip > address, > to port 2020. After much research and observation using tools such > as netstat, we've think we at least understand a little more about what is > going on: > > 1) the issue never occurs when running the Remedy client on the Remedy > Server itself. It also > does not seem to occur in the server room itself, when my laptop running > client is plugged into > the same switch. > > 2) the client PC running the remedy client software seems to experience the > delay after EXACTLY > one hour, possibly indicating that something, somewhere is timing out, after > 60 minutes. > > While the Remedy server port is now always 2020, the client seems to pick a > random port > for its side of the connection (e.g. 5617), and right after an hour, when > the server and client > try to re-connect as you press the button doing something in the client, the > spinning donut > or "hang" appears to be due to the client re-negotiating this link... > because immediately after > the donut disappears, there is a new port on the client side (e.g. 5623). > Is there a way to > permanently set the outgoing port on the client? This could help, or at > least force a real > timeout errror to show up in the logs, if that original port really did get > shut off. > > 3) we have one smart user who shared with us that he sets "auto-refresh" in > his Remedy > client to avoid the problem. We don't want to recommend this to all users, > since this could > work but create an extra load on the database. Right now our security > network person > is trying to find out if the Palo Alto Networks firewall has some inbuilt > timeout after 60 > minutes that could be the root of the problem. > > Thanks for any comments, advice, or sharing about your similar experience. > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
