I received an update from BMC on this issue. The defect they
generated was CLOSED with a disposition of AS DESIGNED. I do not
agree with this decision, and I want to stir up some discussion in the
community as to their stated direction, and my perceived DOA status of
the mid-tier product in large scale environments as a result of this
statement of direction:
I received this update from BMC:
The defect related to this issue: SW00264036 was closed with the
following comments:
Re midtier behavior, http is stateless so all user states are tracked
on the midtier side. If the user closes all browser windows associated
with a valid http session on midtier side, the session will remain
until expires. This means, any license acquired on behalf of the user
will not be release until session times out. The behavior is as
designed. (In contrast to WUT which uses RPC, when the WUT is closed,
it calls back to the AR Server to perform logout. If TCP is lost when
the user closes WUT, then the license for that user also stays in
limbo until times out.)
This was the response back to BMC:
- One aspect of the issue we raised was that we had added an Active
Link that fires on Window Close to do the PERFORM-ACTION-EXIT-APP
process, but that does not release the token either. I do not see the
explanation below addressing that at all.
- Also, I just ran a test to prove/disprove the statement below
regarding the MT session handling. I set the session timeout to 2
minutes on my Mid-Tier, logged in to MT w/ a floating license, killed
the browser window, verified the user was still in possession of a
floating token via the Manage User Licenses in the admin tool, and
then waited about 10 minutes. The floating token had still not been
released even though the session should have expired.
Axton Grams
On 3/22/07, Axton <[EMAIL PROTECTED]> wrote:
> Using IE, it will appear the browser is timing out; you will need to
> look at the servletexec stderr logs to see the java stack trace
> triggered by the null pointer exception.
>
> Axton Grams
>
> On 3/22/07, Axton <[EMAIL PROTECTED]> wrote:
> > Daniel, create an active link that performs an open window using the
> > current window (AL should fire from the form that has the AL that
> > performs the exit-app on window close). Let me know if you get a null
> > pointer exception.
> >
> > Axton Grams
> >
> > On 3/22/07, CONDREA, Daniel <[EMAIL PROTECTED]> wrote:
> > > Hi All ,
> > >
> > > Yesterday I said that a floating license is not release.
> > >
> > > I was wrong. The reason is that I had performed the test in the
> > > following condition:
> > >
> > > - ARS version 6.3 patch 21
> > > - AR mid tier 7.0.1 patch 001
> > > - IIS 6.0 on Win 2003 SP2
> > > - IE 7.0
> > > - New Atlanta 5.0
> > >
> > > Today using the same mid tier but connected to ARS version 7.0.1 running
> > > on MS SQL 2005 SP2, the test was a success.
> > >
> > > Steps to reproduce:
> > >
> > > - create a regular form
> > > - create an AL running on Windows Close event with Run Process
> > > PERFORM-ACTION-EXIT-APP
> > >
> > > Regards,
> > > Daniel
> > >
> > >
> > > -----Original Message-----
> > > From: Action Request System discussion list(ARSList)
> > > [mailto:[EMAIL PROTECTED] On Behalf Of ARSList
> > > Sent: Tuesday, March 20, 2007 7:46 PM
> > > To: [email protected]
> > > Subject: Re: Freeing licenses
> > >
> > > Shouldn't the Mid-Tier "Session Timeout" take care of the license?
> > >
> > > I would think when the users closes the browser after this timeout
> > > happens, the license should be released.
> > >
> > > I would test this in my lab, but I don't have the ($$$) floating
> > > licenses for my test.
> > >
> > > Nick
> > >
> > > -----Original Message-----
> > > From: Action Request System discussion list(ARSList)
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> > > Sent: Sunday, March 18, 2007 11:06 AM
> > > To: [email protected]
> > > Subject: Re: Freeing licenses
> > >
> > > I built another environment as follows and retested the behavior:
> > > - 7.x def used for testing available at
> > > http://arswiki.org/dist/ars/AppClose.def
> > >
> > > *** Steps to reproduce the issue (method 1):
> > > 1-after importing the def, go to the home page on the mid-tier server
> > > 2-open the TestAppCloseLicenseUsage/Console entry point 3-click the
> > > 'open in current' button on the console form (this performs an open
> > > window action in the current window) - you will receive a hang in the
> > > app; click stop script to continue if using IE 4-close the window
> > >
> > > This terminates all browsers, the main console has an AL to exit-app on
> > > window close, but the license remains allocated.
> > >
> > > Expected Result:
> > > - Floating license is releases
> > > Actual Result:
> > > - Floating license remains allocated
> > >
> > > *** About the stop script error:
> > > When you have an AL on a form that perform the exit-app run process on
> > > window close, and you perform an open window action to the current
> > > window, this causes an error. In IE you are presented with the option
> > > to stop/continue the script. In Firefox, you get a java stack trace:
> > >
> > > Mar 18, 2007 1:55:19 PM - SEVERE (com.remedy.log.SERVLET) : (Thread
> > > 11) Caught RuntimeExceptionjava.lang.NullPointerException
> > > at com.remedy.arsys.goat.FormContext.<init>(Unknown Source)
> > > at com.remedy.arsys.stubs.GoatServlet.postInternal(Unknown
> > > Source)
> > > at com.remedy.arsys.stubs.GoatHttpServlet.doGet(Unknown Source)
> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> > > tionFilterChain.java:269)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> > > erChain.java:188)
> > > at
> > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> > > e.java:210)
> > > at
> > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> > > e.java:174)
> > > at
> > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> > > :127)
> > > at
> > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> > > :117)
> > > at
> > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> > > java:108)
> > > at
> > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
> > > 51)
> > > at
> > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:87
> > > 0)
> > > at
> > > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
> > > essConnection(Http11BaseProtocol.java:665)
> > > at
> > > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
> > > .java:528)
> > > at
> > > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
> > > erWorkerThread.java:81)
> > > at
> > > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
> > > .java:685)
> > > at java.lang.Thread.run(Thread.java:595)
> > >
> > > It would appear that the exit-app run process ran (partially at least),
> > > and an exception was thrown when the form attempted to reuse the current
> > > browser window. To sum it up, using an open window action in tthe
> > > current window causes a null pointer exception to be thrown if the
> > > parent form has an AL that performs the exit-app run process on window
> > > close. The exception is not thrown when the active link (exit-app on
> > > win close) is disabled; but the license is not released either when the
> > > form is closed.
> > >
> > > Hopefully this helps you see the catch22 of using this approach and why
> > > it is not a viable alternative. The mid-tier just needs to be fixed to
> > > handle this properly, which as I see it: when a browser session
> > > terminates, the mid-tier should be responsible for reaping all licenses
> > > associated with that session; the same as closing the user tool. Remedy
> > > customers should not be responsible for coding around this flaw; which,
> > > to address the issue properly and without introducing errors, can be a
> > > complex task.
> > >
> > > *** Environment Information:
> > > - ARServer 7.0.01 patch 001 200701111654 on Win2003
> > > - Mid-tier 7.0.01 Patch 001 200701091113 on CentOS 4.4 with
> > > 2.6.9-023stab040.1-enterprise kernel
> > > - Oracle 10g on CentOS 4.4 with 2.6.9-023stab040.1-enterprise kernel
> > > - Tomcat 5.5.23
> > > - Sun JDK build 1.5.0_11-b03
> > > - Authentication was performed using standard Remedy passwords
> > >
> > > *** Browsers Tested (all failed):
> > > - Firefox 1.5.0.10
> > > - Firefox 2.0.0.2
> > > - IE 7.0.5730.11
> > >
> > > Axton Grams
> > >
> > > On 3/18/07, Axton <[EMAIL PROTECTED]> wrote:
> > > > Except that David's approach doesn't work. I tested it, have you? I
> > > > even went so far as to have a third party test it; they got the same
> > > > results I. I'm just trying to save you from spinning your wheels
> > > > needlessly; take it or leave it.
> > > >
> > > > Go ahead and write the workflow in the manner David suggested and see
> > > > if it makes a difference.
> > > >
> > > > Axton
> > > >
> > > > On 3/17/07, CONDREA, Daniel <[EMAIL PROTECTED]> wrote:
> > > > > Axton you just want to find out how smart you are.
> > > > >
> > > > > David J. Easter, Sr. Product Manager - BMC Software, suggested
> > > > > "PERFORM-ACTION-EXIT-APP" and, in my opinion, he is smarter than
> > > you.
> > > > > David's suggestion is simpler and releases a licenses immediately
> > > while
> > > > > yours is very complicated and cost to much.
> > > > >
> > > > > Daniel
> > > > >
> > > > > -----Original Message-----
> > > > > From: Action Request System discussion list(ARSList)
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> > > > > Sent: Sunday, March 18, 2007 12:15 AM
> > > > > To: [email protected]
> > > > > Subject: Re: Freeing licenses
> > > > >
> > > > > You could write a simple program to scan/release licenses using perl
> > > or
> > > > > java. If you wanted to get a little fancier, you could write the
> > > api to
> > > > > cross-reference mid-tier/servlet/web server sessions to arserver
> > > > > sessions, then drop the ones initiated from the web that no longer
> > > have
> > > > > a valid web/servlet session. Just an idea, and I am sure there are
> > > some
> > > > > details that would have to be ironed out. If you kept the api
> > > simple,
> > > > > you could call it on window close from an active link; this would do
> > >
> > > > > what the run process command (exit-app) is supposed to do, but
> > > doesn't.
> > > > >
> > > > > I would also suggest you register with the bugzilla app I set up and
> > >
> > > > > register your votes against this defect, if you haven't already.
> > > > > Public involvement in this app is going to be the catalyst for BMCs
> > > > > involvement. I see 3 people from BMC registered now, just waiting
> > > at
> > > > > this point to see what they plan to do. http://arswiki.org/bugs
> > > > >
> > > > > Another option, you could pressure support to flag the issue as a
> > > > > defect, then wait on a fix.
> > > > >
> > > > > Axton Grams
> > > > >
> > > > > On 3/17/07, ARSList <[EMAIL PROTECTED]> wrote:
> > > > > > Axton,
> > > > > >
> > > > > > Can you suggest ways for me to set this auto-logout based on
> > > either
> > > > > > escalation or interval due to my organizations secure-web
> > > > > > timeout-disconnect? (This disconnect happens 20 minutes when
> > > there is
> > > > >
> > > > > > no activity.) I am trying to not only make the floating license
> > > > > > time-out issues work, but satisfy my users as well.
> > > > > >
> > > > > > I appreciate all of your help - beyond my issues, but helping
> > > everyone
> > > > >
> > > > > > else too!
> > > > > >
> > > > > > Nick Hromyak
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Action Request System discussion list(ARSList)
> > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> > > > > > Sent: Friday, March 16, 2007 4:06 PM
> > > > > > To: [email protected]
> > > > > > Subject: Re: Freeing licenses
> > > > > >
> > > > > > It's probably not a problem with it firing before the browser
> > > closes;
> > > > > > but instead is a problem that the run process and logoutservlet
> > > just
> > > > > > flat out don't work a lot of the time (6.3-7.0.1):
> > > > > >
> > > > > > http://arswiki.org/bugs/show_bug.cgi?id=10
> > > > > >
> > > > > > Axton Grams
> > > > > >
> > > > > > On 3/16/07, ARSList <[EMAIL PROTECTED]> wrote:
> > > > > > > Thank you for the tips, suggestions and Definition files.
> > > > > > >
> > > > > > > However...
> > > > > > >
> > > > > > > I have not been able to get this to work as an AL on Window
> > > Close
> > > > > > > through the Mid-Tier (Servlet 5.0.13, Java 1.4.2_13) 6.03 Patch
> > > 20.
> > > > > > >
> > > > > > > I am using the Form Remedy Support, AL Run Process -
> > > > > > > PERFORM-ACTION-EXIT-APP Basically I copied the DEF file you
> > > > > > > supplied and manually entered the Buttons and AL with a common
> > > > > > > form.
> > > > > > > Then I moved the AL to the above information duplicating the
> > > > > "Logout"
> > > > > > > button from the form in the Remedy Support. I confirmed the
> > > Logout
> > > > > > > Button AL in the Remedy Support form does the same Run Process -
> > >
> > > > > > > PERFORM-ACTION-EXIT-APP.
> > > > > > >
> > > > > > > I think the Mid-Tier / Internet Explorer (IE) does not provide
> > > the
> > > > > > > feedback in the Mid-Tier before the IE actually closes.
> > > > > > >
> > > > > > > I am beginning to think I should use the Interval AL. But I am
> > > not
> > > > > > sure
> > > > > > > what the Interval means? Could it (as I hope, but doubt) mean
> > > the
> > > > > > > interval when there is no activity by the user?
> > > > > > >
> > > > > > >
> > > > > > > Basically, if there is no activity by my user with the interval
> > > in
> > > > > > > 600 seconds, I want them to get logged out... right?
> > > > > > > (The trick)
> > > > > > > If there is activity (how do I monitor this) can I stop this
> > > > > interval?
> > > > > > >
> > > > > > > Perhaps I should use (the one I don't know anything about) are
> > > > > > > escalations?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Action Request System discussion list(ARSList)
> > > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> > > > > > > Sent: Tuesday, March 13, 2007 7:31 PM
> > > > > > > To: [email protected]
> > > > > > > Subject: Re: Freeing licenses
> > > > > > >
> > > > > > > Not if you explicitly end the session, it is supposed to be
> > > released
> > > > >
> > > > > > > immediately. Think of closing your user tool, that releases a
> > > > > > > floating license; why should the same not apply to the mid-tier.
> > > > > > > The logout servlet is supposed to do the same, but it doesn't
> > > some
> > > > > > > of the time.
> > > > > > >
> > > > > > > In all honesty, closing the browser should release the token,
> > > the
> > > > > > > same as the user tool does. It should just be built into the
> > > > > > > mid-tier. A lost session (i.e., logout or close browser) should
> > >
> > > > > > > release the license immediately (no exceptions), to stay true to
> > > the
> > > > >
> > > > > > > nature of the licenses as they are managed when using the user
> > > tool.
> > > > >
> > > > > > > In all honesty, I think that until the mid-tier behaves in that
> > > way,
> > > > >
> > > > > > > it is defective.
> > > > > > >
> > > > > > > Axton Grams
> > > > > > >
> > > > > > > On 3/13/07, Rocky Rockwell <[EMAIL PROTECTED]> wrote:
> > > > > > > > The last I heard license assigned to a user will stay with the
> > >
> > > > > > > > user
> > > > > > > for
> > > > > > > > a minimum of 1 hour (configured in the admin tool). This is
> > > the
> > > > > > least
> > > > > > > > about of time you can set.
> > > > > > > >
> > > > > > > > *Rocky*
> > > > > > > >
> > > > > > > > Rocky Rockwell
> > > > > > > > eMA Team - Remedy Developer
> > > > > > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > > > > > > > Ph#1: 214-567-8874
> > > > > > > > Ph#2: 325-884-1263
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Wheeler, Dylan wrote:
> > > > > > > > > **
> > > > > > > > >
> > > > > > > > > Hi List,
> > > > > > > > > So I'm running into a problem with my licenses. We don't
> > > quite
> > > > > > have
> > > > > > > > > enough so I've been playing around trying to get the
> > > licenses
> > > > > > freed
> > > > > > > up
> > > > > > > > > when I can. I'm finding that the licenses on my server are
> > > > > > sticking
> > > > > > > no
> > > > > > > > > matter what though and I'm not sure what's keeping them
> > > there.
> > > > > > > > >
> > > > > > > > > If I open IE and login then click the logout button on the
> > > Home
> > > > > > Page
> > > > > > > > > it should release the license right? The license is still
> > > > > > > > > showing
> > > > > > as
> > > > > > > > > taken 15 minutes later in my admin tool.
> > > > > > > > >
> > > > > > > > > I created an AL and put in the PERFORM-ACTION-EXIT-APP
> > > command,
> > > > > > > > > execute on window close and left the run if open,
> > > permissions
> > > > > > > > > are
> > > > > > > set
> > > > > > > > > to public. Closing the Home Page in the user tool will close
> > > out
> > > > > > the
> > > > > > > > > application, but the license is still active. Closing the
> > > window
> > > > > > on
> > > > > > > > > the mid tier will leave the license active.
> > > > > > > > >
> > > > > > > > > Anyone run into this or have a clue what could be causing
> > > it?
> > > > > > > > > ARS/Mid Tier 6.3 Patch 21
> > > > > > > > > IIS on Windows 2003
> > > > > > > > >
> > > > > > > > > *-------------*
> > > > > > > > >
> > > > > > > > > *Dylan Wheeler*
> > > > > > > > > *Production Control Analyst Principal* *IT Operations*
> > > *Downey
> > > > > > > > > Savings & Loan Association, F.A. *
> > > > > > > > > *Email: [EMAIL PROTECTED]
> > > > > > > > > <mailto:[EMAIL PROTECTED]>
> > > > > > > > >
> > > > > > > > > This message and any attachments are for the intended
> > > > > > > > > recipient(s) only and may contain privileged, confidential
> > > > > > > > > and/or proprietary information about Downey Savings or its
> > > > > > > > > customers, which Downey Savings does not intend to disclose
> > > to
> > > > > > > > > the public. If you received this message by mistake, please
> > > > > > > > > notify the sender by reply e-mail
> > > > > > > and
> > > > > > > > > delete the message and attachments.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > This message and any attachments are for the intended
> > > > > > > > > recipient(s) only and may contain privileged, confidential
> > > > > > > > > and/or proprietary information about Downey Savings or its
> > > > > > > > > customers, which Downey Savings does not intend to disclose
> > > to
> > > > > > > > > the public. If you
> > > > > > received
> > > > > > > > > this message by mistake, please notify the sender by reply
> > > > > > > > > e-mail
> > > > > > > and
> > > > > > > > > delete the message and attachments.
> > > > > > > > >
> > > > > > > > > __20060125_______________________This posting was submitted
> > > with
> > > > > > > HTML
> > > > > > > > > in it___
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > ______________________________________________________________________
> > > > > > __
> > > > > > > _______
> > > > > > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > > > > > > ARSlist:"Where the Answers Are"
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > ______________________________________________________________________
> > > > > > __
> > > > > > > _______
> > > > > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > > > > > ARSlist:"Where
> > > > > > > the Answers Are"
> > > > > > >
> > > > > > >
> > > > > >
> > > ______________________________________________________________________
> > > > > > __
> > > > > > _______
> > > > > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > > > > > ARSlist:"Where the Answers Are"
> > > > > > >
> > > > > >
> > > > > >
> > > ______________________________________________________________________
> > > > > > __
> > > > > > _______
> > > > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > > > > > ARSlist:"Where the Answers Are"
> > > > > >
> > > > > >
> > > ______________________________________________________________________
> > > > > > _________ UNSUBSCRIBE or access ARSlist Archives at
> > > www.arslist.org
> > > > > > ARSlist:"Where the Answers Are"
> > > > > >
> > > > >
> > > > >
> > > ________________________________________________________________________
> > > > > _______
> > > > > 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"
> > > > >
> > > >
> > >
> > > ________________________________________________________________________
> > > _______
> > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> > > the Answers Are"
> > >
> > > ________________________________________________________________________
> > > _______
> > > 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"
> > >
> >
>
