Hi All, I tested OK on ARS version 7.0.1 patch 002 with midier 7.0.01 Patch 001 200701091113, ServletExec/5.0, Java Version 1.4.2_13, Win 2003 SP2 Regards, Daniel
________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of patrick zandi Sent: Friday, April 27, 2007 3:58 PM To: [email protected] Subject: Re: Freeing licenses ** Axton, In priciple you are correct. The argument has moved though.. now remedy is stating that there is a fix with Mid-tier 7.01. P2. Unfortuanately it will not work with RemedySSO. So I would test this and find out if it is really fixed. But from the other side, it should be still considered a bug and Fixed on previous versions. it definately should not have gone on this long, through some 7.0/ 7.0P1/ 7.0P2/ 7.01P1 versions prior to getting fixed. Would like to hear the results of this. Actually I have a Bug number to go with it:: SW00252140 <<----------------------- This is the same issue right ? 1. DROP/BUILD BUG OCCURS IN (IF PRE-RELEASE) Tested against latest build of 7.0.1 mid-tier and 7.0 patch 001. Reproduces so far on any application server that supports HttpSession persistance, tested on Tomcat and ServletExec. Problem does not reproduce with 6.3 mid-tier patch 018. 2. STEPS TO REPRODUCE: There's actually two different ways to reproduce this problem. The key to reproducing is to be using a Application server/Servlet engine that saves Http sessions across restarts, such as Tomcat standalone, this product will save any created sessions to a file called SESSIONS.ser and reload them on restart. This was tested using a non admin user with a Floating write license, not sure if floating vs. fixed license matters or not, just used floating since that's what the customer is using. Also in mid-tier config using 1 arserver for preference, home page and ar server list. Method 1 to reproduce: -Stop Tomcat, remove the SESSIONS.ser file from the C:\Program Files\Apache Group\Tomcat 4.1\work\Standalone\localhost\70p1 directory or equivelent directory on your local install. Start Tomcat. This ensures that no prior saved sessions are loaded. - Restart arserver. This ensures that the user's cached login structure is cleared from arserver memory. - Login at PC #1, mid-tier successfully runs ARVerifyUser in LoginServlet authenticate() method, then clears the ARServerUser login context. - Close all browser windows. - Restart Tomcat, but don't delete the SESSIONS.ser file. - Login at PC #1 again. Now when mid-tier calls ARVerifyUser it returns ARERR 9093. Unfortunately the authenticate method in LoginServlet is only specifically looking for either a ARERR 623 or ARERR 612, any "other" error from the arserver, such as a 90, 91, 9093, etc. is just treated with as a blanket authentication failed and we display a dialog box showing ARERR 9388 "Authentication Failed" to the user at login.jsp. This doesn't give the user a chance to say Yes they would like to override the login for the 9093 error. The user is basically locked out of the system, they're stuck in a catch 22. Also, interesting enough the new IP address showing in arerror.log showing is not a GUID that we would expect from a web client, instead it's the IP address of the machine mid-tier is running on. Method 2 to reproduce: -Stop Tomcat, remove the SESSIONS.ser file from the C:\Program Files\Apache Group\Tomcat 4.1\work\Standalone\localhost\70p1 directory or equivelent directory on your local install. Start Tomcat. This ensures that no prior saved sessions are loaded. - Restart arserver. This ensures that the user's cached login structure is cleared from arserver memory. - Login at PC #1, mid-tier successfully runs ARVerifyUser in LoginServlet authenticate() method, then clears the ARServerUser login context. - Login at PC #2, mid-tier successfully runs ARVerifyUser in LoginServlet authenticate() method, then clears the ARServerUser login com On 4/26/07, Axton <[EMAIL PROTECTED]> wrote: Last message bounced because it was too long. I know one is stateful and the other is stateless, but once the browser's license is in limbo, there is no way to release it, not even logging back in and clicking logout will release the license. The precedence as to what is expected from floating licenses was set with the user tool over the last 14 years. Any web interface that is developed needs to exist, at a minimum, within the confines of this precedence. This can be measured by determining if you need to purchase additional licenses to effectively utilize an interface that is bundled with the arsever. Why not extend the current architecture and create a session object for each window that gets opened, then use the javascript unload listener to remove the session object when a window is closed (by clicking X). Each time a window is closed (js unload event), the javascript could check to see if the session object for that window is the last one, and if it is, creates an xmlhttprequest, sends the request to a servlet to end the session ( e.g., release the licenses). A cookie could be used instead of a session object if desired. A simple example of the unload event can be viewed at: http://www.dcs.uwaterloo.ca/~anderson/JavaScript/ex_load_unload.html This javascript fires when I click the X in the browser window; why not use the same hook for the mid-tier? Why could the unload event not create an xmlHttpRequest, send the request to a servlet within the mid-tier to end the session (e.g., release the licenses). Unless I'm totally missing something, it looks like the hooks are there, but the code to utilize them is not. I'm not saying it's a simple thing to write, but it looks to be possible. A more direct question to BMC. If this is the current situation, how am I supposed to roll this out for wide-scale usage without the hundreds of thousands of dollars I would need to purchase additional floating licenses? Take my scenario as an example. I have an approval process. Users approve requests through the mid-tier. When an approval process is started, 40 to 50 signature lines are generated. Roughtly 80% of the approver base has a floating licenses (note that the approval interface is fully capable of operating with a read license). Now I have up to 50 people hitting my mid-tier server at roughly the same time (let's say within the same hour). None of them click the logout button after approving their request. Now I have 40-50 of my 220 floating licenses tied up for the next hour. I start to get a flood of ticket from my support desk, operations center, etc. that they are receiving some type of error constantly popping up on their screen stating: No free floating write license tokens available. What are my options here? - don't use the mid-tier? - buy another 50 floating licenses? - write my own web application that effectively manages floating licenses? - tell my users to live with the error, and notify them they can't user remedy until they stop getting the error, which should hopefully occur within the next hour some time? None of these are good options when all I need is a web interface into my Remedy server that is capable of operating under the same licensing requirements as the native client. Let's face it, users are going to click the X in the top right corner when they are done using the mid-tier. It's what people do when they are through using a web browser and it's something that has to be dealt with. Axton Grams On 4/26/07, Easter, David <[EMAIL PROTECTED]> wrote: > You may also wish to compare apples to apples. Your tests are closing > the browser window without logging out. This would be equivalent to the > statement you made about the WUT: > > > If TCP is lost when the user closes WUT, then the license for that > user also stays in limbo until times out. > > If one clicks on the "Logout" link within the web client, the license > should be released properly just as if you'd closed the WUT. If one > closes the browser without logging out, you've effectively created the > situation where no message is sent back to AR System (i.e. just like if > TCP is lost for the WUT). > > Because each browser window is self-sufficient (i.e. there's no parent > window that contains all of the sub-windows), there's currently no > simple way for AR System to know that the closing of a specific window > (i.e. by killing the browser or clicking on the 'x') indicates that all > windows should now be invalid. > > More simply put - Let's say you have browser windows 1, 2, and 3 open. > You 'x' out of window 2. Should Windows 1 and 3 become invalid? Most > folks would say 'no'. Each window is independent. Window 1 doesn't > know about Window 2 and 3. So when Window 2 closes, 1 and 3 keep > running. > > If you close Windows 1 and 3 using the 'x', AR System still doesn't know > if Window 2 is there or not (remember, you clicked on the 'x' - not > logout). Since you closed the browser and did not logout, no message is > sent back to AR System letting the Mid-Tier know that the user isn't > just sitting there idle. So the timeout starts ticking down... > > In the WUT, you have a central application which governs all "windows". > If you close out a form, you have not left the central application (i.e. > the WUT). When you do close the WUT, it's obvious that all sub windows > should be closed. > > A longer term solution for this is certainly something being considered > - but the unique differences between a web session and a local > application will need to be overcome. There are obviously ways to do it > (e.g. you could make the AR System web GUI a flash/Java application with > all windows contained within the single app; you could disable > multi-window capability and have only one browser window in use at a > time using forward/backward paging; designate one window as the "parent" > window and when you close that, all other windows become invalid, etc. ) > - one would have to be sure that the method chosen fulfills all of the > usage cases and does not disrupt the use of the product that folks are > used to. > > -David J. Easter > Sr. Product Manager, Service Management Business Unit > BMC Software, Inc. > > 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. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -- Patrick Zandi __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
-- *****DISCLAIMER***** The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Orange Romania S.A. is neither liable for the proper, complete transmission of the information contained in this communication nor any delay in its receipt. *****END OF DISCLAIMER***** _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
