File descriptors to log buffers are not released after publications are shutdown.

[bedding]

I ran into the same issue on this ticket: #329 a few days ago. I updated to the 1.2.4, and now the space are freed but the file descriptors are still held by the aeron client process.

In my case, I need to add and remove publications/subscriptions occasionally and I would like the code to run almost 24/7 without restarting. Linux has a limitation on the number of files that a process can open, which is 65535 on my machine. Since the aeron client code never releases the file descriptor even the log buffer itself is deleted, the process will eventually run out of fds, which will further lead to the pretty bad situation where no more files can be opened, no publication can be added and you can even open a socket.

[mjpt777]

Can you check with Aeron 1.2.5 which has just been released?

[tmontgomery]

I'm not able to see this with either a single publication or a single subscription. lsof reports no FDs or mappings in use after either a Publication.close or an UnavailableImage.

What is the pattern of usage for publications and subscriptions you have?

Or do you have something simple that reproduces this?

Update: is this C++ or Java?

[bedding]

The sub/pub pattern is like,

class A
{
    std::shared_ptr<aeron::Publication> pub;
    std::shared_ptr<aeron::Subscription> sub1; // subscribe to B::pub1
    std::shared_ptr<aeron::Subscription> sub2; // subscribe to B::pub2
};

class B
{
    std::shared_ptr<aeron::Subscription> sub;
    std::shared_ptr<aeron::Publication> pub1;
    std::shared_ptr<aeron::Publication> pub2;
};

Instances of class A and B are created/deleted occasionally, but they are always deleted as a pair

[tmontgomery]

mapExisting for C++ did not have a close of the FD. Give the latest a shot (not 1.2.5 unfortunately as this change happened after the release) and see if the FDs are around or not.

[bedding]

The above commit did fix it for me. Thanks a lot!

[sthornington]

👍