Skip to content

Add completed() to SftpEventListener complementing received() #757

@pruy

Description

@pruy

Description

The received() method of the SftpEventListener allows to hook in before a command is executed.
This is already occurring with the thread that is executing the command.
It allows for setup activities needed when attaching a custom filesystem to the server.
A corresponding method being called AFTER a command has been executed does not exist.
There seems not to be any chance to hook into command completion before the thread is released
in order to execute tear down activities after a command has executed.

All operation specific activities have complementing listener methods
(opening() vs open()/openFailed(), removing() vs removed(),...).

I am undecided whether there should be a single method is sufficient
or there should be a pair of methods, one for regular termination and one for termination by exception.

Motivation

I am using sftp server for accessing application data from a database and presenting this in a filesystem like view.
Authentication convention with the existing application require a per thread initialization.
Not being able to clean up after command execution leaks resources that have been allocated during command execution.
Such resources are tied to the thread and expected to be cleaned up at end of execution (thread being terminated).
As sftp (and the ssh layer above) are making heavy use of threads during operation
there are lots of resources allocated that are not getting released timely enough.
This causes resource outages long before any true load is being handled.

Alternatives considered

It is possible to do clean up at session termination.
But if a user keeps a session open for long and
especially is doing lots of commands within,
this will use huge amounts of resources that actually could be freed
and used with other activities (even of the same session).

Also adding cleanup code to any specific operation completion listener method
is quite tedious and is exposed to the risk that later extensions of commands
may miss adding the proper activities to the then to be added new listener method.

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions