/**
 * This is used for durable sessions, that is sessions in MQTT that are not "clean" sessions (and with QoS >= 1
 * subscriptions) and durable AMQP queues, with real-time communication and reliable delivery that requires tracking
 * delivery and acknowledgement. This particular function is used to start or retrieve such a session.
 * A session can be durable (maintains state) or clean (no state). A durable session is stored in a system table as a
 * record that holds a list of subscriptions (topic and QoS), the timestamp of last message, and any unacked messages
 * before the timestamp. Once this is returned, it makes the subscription "live", actively routing data through it. Any
 * catch-up from topics, that is subscriptions to records, need to be performed first.
 * The structure is designed such that no changes need to be made to it while it is at "rest". That means that if there
 * are no active listeners to this session, no active processing of subscriptions and matching messages needs to be
 * performed. All subscription handling can be resumed when the session is reconnected, and can be performed on the
 * node that is active. The timestamps indicate all updates that need to be retrieved prior to being live again.
 * Note, that this could be contrasted with a continuously active session or queue, that is continually monitoring
 * for published messages on subscribed topics. This would require a continuous process to perform routing, and on
 * a distributed network, it could be extremely difficult and unclear who should manage and handle this. This would also
 * involve extra overhead when sessions are not active, and may never be accessed again. With our approach, an
 * abandoned durable session can simply sit idle with no resources taken, and optionally expired by simply deleting the
 * session record at some point.
 * However, because resuming durable sessions requires catch-up on subscriptions, this means we must have facilities in
 * place for being able to query for the log of changes/messages on each of the subscribed records of interest. We do
 * this by querying the audit log, but we will need to ensure the audit log is enabled on any tables/records that receive
 * subscriptions.
 * @param sessionId
 * @param user
 * @param nonDurable
 */
export declare function getSession({ clientId: sessionId, user, clean: nonDurable, will, keepalive, }: {
    clientId: any;
    user: any;
    listener: Function;
    clean?: boolean;
    will: any;
    keepalive?: number;
}): Promise<any>;
type Acknowledgement = {
    topic?: string;
    timestamp?: number;
    acknowledge?: () => any;
};
declare class SubscriptionsSession {
    listener: (message: any, subscription: any, timestamp: any, qos: any) => any;
    sessionId: any;
    user: any;
    request: any;
    socket: any;
    subscriptions: any[];
    awaitingAcks: Map<number, Acknowledgement>;
    sessionWasPresent: boolean;
    keepalive: number;
    keepaliveTimer: any;
    constructor(sessionId: any, user: any);
    addSubscription(subscriptionRequest: any, needsAck: any, filter?: any): Promise<any>;
    resume(): void;
    needsAcknowledge(update: any): number;
    acknowledge(messageId: any): void;
    removeSubscription(topic: any): Promise<boolean>;
    publish(message: any, data: any): Promise<any>;
    createContext(): any;
    setListener(listener: (message: any) => any): void;
    disconnect(clientTerminated: any): void;
    receivedPacket(): void;
}
export declare class DurableSubscriptionsSession extends SubscriptionsSession {
    sessionRecord: any;
    constructor(sessionId: any, user: any, record?: any);
    resume(): Promise<void>;
    resumeSubscription(subscription: any, needsAck: any, filter?: any): Promise<any>;
    needsAcknowledge(update: any): number;
    acknowledge(messageId: any): void;
    addSubscription(subscription: any, needsAck: any): Promise<any>;
    removeSubscription(topic: any): Promise<boolean>;
    saveSubscriptions(): void;
}
export {};
