**
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___
