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"
