OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-263) Simplified State Management


    [ https://issues.oasis-open.org/browse/MQTT-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62279#comment-62279 ] 

Ken Borgendale commented on MQTT-263:
-------------------------------------

The discussions in Bellevue ended with a statement that what we really wanted was the will delay as there were good reasons for session expiration and will delay to be different.  The way to deal with the session expiration and will delay is to say that if the session is discarded (for whatever reason) before the will delay has elapsed then the will message is sent.  

I disagree with the statement "the session state must not be discarded if the Client reconnects within the duration interval".  We must allow the server to discard the session based on its own administrative settings.  This includes but is not limited to  configurations to allow non-persistence, server resource limitations, client quota limitations, direct admin actions, hardware failure, and maximum session life configuration.  We already have both automatic and manual methods for session state to be discarded by the server, and this is clearly allowed in the V3.1.1 spec.

The setting of the optional session state expiration interval is a request by the client that it would like the session to remain for this amount of time.  It does not obligate the server to keep the session state for that amount of time.  

> Simplified State Management
> ---------------------------
>
>                 Key: MQTT-263
>                 URL: https://issues.oasis-open.org/browse/MQTT-263
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>            Reporter: Peter Niblett
>
> There could be some more things we do in CONNECT and DISCONNECT to make it easier for client applications to manage stateful Sessions. For example we could consider an option on DISCONNECT that requests an immediate destruction of server state (e.g. pending messages and subscriptions)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]