[ https://issues.apache.org/jira/browse/VCL-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Thompson updated VCL-568: ------------------------------ Description: It would be useful to refresh the current reservations page shortly after a timeout could have occurred so that users will see if the reservation timed out. We'll key off events in computerloadlog. Two entries will be created in the variable table - acknowledgetimeout and connecttimeout that will have values that are the timeout period in seconds. One entry will be added to computerloadstate - connecttimeout. When vcld inserts the 'reserved' computerloadstate into computerloadlog, both vcld and the frontend will key off of that timestamp and variable.acknowledgetimeout to know when the reservation will timeout if the user does not click the Connect button. When the user clicks the Connect button, the frontend will insert an entry into computerloadlog for connecttimeout. Both vcld and the frontend will key off of that timestamp and variable.connecttimeout to know when the reservation will timeout if the user never connects. was: It would be useful to refresh the current reservations page shortly after a timeout could have occurred so that users will see if the reservation timed out. We'll key off events in computerloadlog. Two entries will be created in the variable table - acknowledgetimeout and connecttimeout that will have values that are the timeout period in seconds. One entry will be added to computerloadstate - connecttimeout. When vcld inserts the 'reserved' computerloadstate into computerloadlog, both vcld and the frontend will key off of that timestamp and variable.acknowledgetimeout to know when the reservation will timeout if the user does not click the Connect button. When the user clicks the Connect button, the frontend will insert an entry into computerloadlog for connecttimeout. Both vcld and the frontend will key off of that timestamp and variable.connecttimeout to know when the reservation will timeout if the user never connects. One more change that is useful here: insert the user's IP address in the reservation table when the reservation is initially created. Then, there will not be anything that needs to happen on the reserved node after the user clicks Connect (unless the image has a vcl_post_reserve script). When vcld sees that computerloadlog has a connecttimeout entry, it will move on to the connect timeout loop and double check that the current value in reservation.remoteIP matches what is in the firewall and adjust accordingly. > refresh current reservations page 15 minutes after a reservation becomes > available > ---------------------------------------------------------------------------------- > > Key: VCL-568 > URL: https://issues.apache.org/jira/browse/VCL-568 > Project: VCL > Issue Type: Improvement > Components: vcld (backend), web gui (frontend) > Reporter: Josh Thompson > Assignee: Josh Thompson > Fix For: 2.3 > > > It would be useful to refresh the current reservations page shortly after a > timeout could have occurred so that users will see if the reservation timed > out. > We'll key off events in computerloadlog. > Two entries will be created in the variable table - acknowledgetimeout and > connecttimeout that will have values that are the timeout period in seconds. > One entry will be added to computerloadstate - connecttimeout. > When vcld inserts the 'reserved' computerloadstate into computerloadlog, both > vcld and the frontend will key off of that timestamp and > variable.acknowledgetimeout to know when the reservation will timeout if the > user does not click the Connect button. > When the user clicks the Connect button, the frontend will insert an entry > into computerloadlog for connecttimeout. Both vcld and the frontend will key > off of that timestamp and variable.connecttimeout to know when the > reservation will timeout if the user never connects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira