This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Publisher
- :
- FlexNet Publisher Forum
- :
- Question: (P1) How do we expect the framework to handle "queued license requests"
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2005
01:45 PM
Question: (P1) How do we expect the framework to handle "queued license requests"
FLEXnet Licensing allows the application an option to "queue" for a license if there are none currently available. Although we did not address the topic when creating the framework, we know of several EDA applications who make us of this feature and it can be troublesome for Grid scheduling.
We would like to clarify the expected behaviour in the framework with license queuing and unsure that we are not making things more difficult for both of us to handle in future revisions.
Our understanding so far from simple testing:
- the framework cannot tell the difference between an application that intends to queue on denial (request option) and ones that does not.
- except that the framework seems to trigger two identical CO requests for a single "queue request"
- if we deny a license explicitly which requester to be queued, it does not queue (this is useful if we new it was asking to queue)
- the framework does not appear to fire at all when a queued application is granted a license (this is our biggest confusion)
If we had some idea that the request asked to be queued (in the request structure) then there are some options on how we could use that information and perhaps this is something very simple to add.
The latter issue of us being aware of the queued license granting we imagine is much larger and would need to considered in a phase 3.
Greg
We would like to clarify the expected behaviour in the framework with license queuing and unsure that we are not making things more difficult for both of us to handle in future revisions.
Our understanding so far from simple testing:
- the framework cannot tell the difference between an application that intends to queue on denial (request option) and ones that does not.
- except that the framework seems to trigger two identical CO requests for a single "queue request"
- if we deny a license explicitly which requester to be queued, it does not queue (this is useful if we new it was asking to queue)
- the framework does not appear to fire at all when a queued application is granted a license (this is our biggest confusion)
If we had some idea that the request asked to be queued (in the request structure) then there are some options on how we could use that information and perhaps this is something very simple to add.
The latter issue of us being aware of the queued license granting we imagine is much larger and would need to considered in a phase 3.
Greg
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2005
05:49 PM
- the framework cannot tell the difference between an application that intends to queue on denial (request option) and ones that does not.
DAVIDZ: You are right that we do not send the {LM_CO_WAIT | LM_CO_NOWAIT | LM_CO_QUEUE} value from the lc_checkout call to either the pre-checkout or post-checkout-failure filters. After reading our answers to the remaining items, let us know if you would still benefit by having this value sent to either filter.
- except that the framework seems to trigger two identical CO requests for a single "queue request"
DAVIDZ: Yes, this is because we invoke the post-checkout-failure filter upon failure or upon the request being queued. We believe this to be a mistake and will change the logic to not call the post-checkout-failure filter after a request has been queued.
- if we deny a license explicitly which requester to be queued, it does not queue (this is useful if we new it was asking to queue)
DAVIDZ: Exactly right, this is intended behavior. The pre-checkout filter is applied before any checkout logic is run, so if your pre-checkout filter denies a license that would queue if the checkout was allowed to continue, a denial is sent back to the client immediately after receiving your denial request, regardless of the queuing suggestion made by the client.
- the framework does not appear to fire at all when a queued application is granted a license (this is our biggest confusion)
DAVIDZ: Our infrastructure supports pre-checkout, post-checkout-failure and post-checkin filters. There is no filter for post-checkout-success or for post-checkout-granted-to-queue-user. Why do you want to filter/monitor license grants to queued users, but not filter/monitor grants to non-queued users? Or is this implicitly a request to filter/monitor license grants to non-queued users too? If so, why? Also, since a queued license is never denied (it will just wait), the post-checkout-failure filter will never need to be called.
David
DAVIDZ: You are right that we do not send the {LM_CO_WAIT | LM_CO_NOWAIT | LM_CO_QUEUE} value from the lc_checkout call to either the pre-checkout or post-checkout-failure filters. After reading our answers to the remaining items, let us know if you would still benefit by having this value sent to either filter.
- except that the framework seems to trigger two identical CO requests for a single "queue request"
DAVIDZ: Yes, this is because we invoke the post-checkout-failure filter upon failure or upon the request being queued. We believe this to be a mistake and will change the logic to not call the post-checkout-failure filter after a request has been queued.
- if we deny a license explicitly which requester to be queued, it does not queue (this is useful if we new it was asking to queue)
DAVIDZ: Exactly right, this is intended behavior. The pre-checkout filter is applied before any checkout logic is run, so if your pre-checkout filter denies a license that would queue if the checkout was allowed to continue, a denial is sent back to the client immediately after receiving your denial request, regardless of the queuing suggestion made by the client.
- the framework does not appear to fire at all when a queued application is granted a license (this is our biggest confusion)
DAVIDZ: Our infrastructure supports pre-checkout, post-checkout-failure and post-checkin filters. There is no filter for post-checkout-success or for post-checkout-granted-to-queue-user. Why do you want to filter/monitor license grants to queued users, but not filter/monitor grants to non-queued users? Or is this implicitly a request to filter/monitor license grants to non-queued users too? If so, why? Also, since a queued license is never denied (it will just wait), the post-checkout-failure filter will never need to be called.
David
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2005
11:52 PM
Lars and I spent several man-hours today trying to determine the best way to support queuing and external filters in the best way.
Every way we tried, we ran into complications which, while not insurmoutable, are not possible to complete between now and Thursday.
On Monday, he and I will diagram the "tree" of possibilities which Platform can use to best support queuing even with 10.8.1.
Our initial guess is that in several scenarios (one of which you already found) unneeded invocations of external filters will be made, but from what we know today, no errors will result. However, we must map out all possibilities on Monday to be sure.
David
Every way we tried, we ran into complications which, while not insurmoutable, are not possible to complete between now and Thursday.
On Monday, he and I will diagram the "tree" of possibilities which Platform can use to best support queuing even with 10.8.1.
Our initial guess is that in several scenarios (one of which you already found) unneeded invocations of external filters will be made, but from what we know today, no errors will result. However, we must map out all possibilities on Monday to be sure.
David
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 27, 2005
07:58 AM
Certainly we would like to have more discussion on the possibilities and see what makes sense.
In particular our difficulty with the current behaviour is that we have no visibility on when a "queued" request is granted. Therefore we might make wrong assumptions about how many licenses are remaining. Simply knowing that a previous request was going to queue would help here.
We have not looked at this in great detail yet but there were two scenarios that immediate came to mind:
1) Prevent any type of application queuing - some argue that queuing should be done on the workload management side and therefore any license queuing in a "Batch Environment" is just a mistaken dispatch. Framework already allows us to deny and not allow the queue but without the knowledge that it will queue (request option).
2) Add intelligence to queuing order - this is a more complicated one. Basically it's building on the idea that FLEXnet offers only FCFS queuing and perhaps LS could add weighted project priority into the mix. We had imagined a scenario on how this would work but it was based on the assumption that the queued application would fire a second "request" when it was being granted a license.
In short, #1 is something we could still offer with only small changes to the framework (more information) while something like #2 needs to be rethought with better understanding of the FLEXnet queuing behaviour.
Greg
In particular our difficulty with the current behaviour is that we have no visibility on when a "queued" request is granted. Therefore we might make wrong assumptions about how many licenses are remaining. Simply knowing that a previous request was going to queue would help here.
We have not looked at this in great detail yet but there were two scenarios that immediate came to mind:
1) Prevent any type of application queuing - some argue that queuing should be done on the workload management side and therefore any license queuing in a "Batch Environment" is just a mistaken dispatch. Framework already allows us to deny and not allow the queue but without the knowledge that it will queue (request option).
2) Add intelligence to queuing order - this is a more complicated one. Basically it's building on the idea that FLEXnet offers only FCFS queuing and perhaps LS could add weighted project priority into the mix. We had imagined a scenario on how this would work but it was based on the assumption that the queued application would fire a second "request" when it was being granted a license.
In short, #1 is something we could still offer with only small changes to the framework (more information) while something like #2 needs to be rethought with better understanding of the FLEXnet queuing behaviour.
Greg
