Forum: VoltDB Architecture

Post: Is it right? -> m_numConnections.get() == MAX_CONNECTIONS.get() <-

Is it right? -> m_numConnections.get() == MAX_CONNECTIONS.get() <-
Edson Ramiro
Aug 29, 2014
Hi everybody,

I was checking the limits of connections on VoltDB (MAX_CONNECTIONS[1]). I saw in the code that the value of MAX_CONNECTIONS is automatically set to FD - 300 (file descriptors).

The condition below may ensure that VoltDB would never accept more connections than the limit.

                    if (m_numConnections.get() == MAX_CONNECTIONS.get()) {


Should the condition be ">=" instead of "=="?

By checking the code I could agree that VoltDB normally will not increase m_numConnections (AtomicInteger) as soon as it reaches MAX_CONNECTIONS.

But I wondering about situations of extreme concurrence (i.e., lots of incoming connections >MAX_CONNECTIONS). In this case, would m_numConnections be set to a value greater than MAX_CONNECTIONS? If so, it could lead VoltDB to accept more transactions then the limit MAX_CONNECTIONS.

Thanks in advance,

[1] https://github.com/VoltDB/voltdb/blob/master/src/frontend/org/voltdb/ClientInterface.java
arogers
Sep 2, 2014
Hello,

So short story, your concern is valid although the problem case is unlikely.

Both the suspect check above and the subsequent incrementing of m_numConnections occur within the run loop of the ClientAcceptor, which is wrapped in a single thread. This is the only place m_numConnections increases in value, so if there were only one ClientAcceptor, the check as currently written would be fine and robust to whatever the world could throw at it.

Unfortunately, there are two ClientAcceptors: a regular and an admin version. Thus, with m_numConnections == MAX_CONNECTIONS - 1, it would be possible for both acceptor threads to hit this check concurrently, resulting in m_numConnections == MAX_CONNECTIONS + 1, which would be sad.

The logic you suggest above is the good, defensive way of doing it. We'll be changing the check accordingly. I've created the following ticket to track the issue:
https://issues.voltdb.com/browse/ENG-6881

Best,
Alex
Edson Ramiro
Sep 12, 2014
Hi Alex,

We found this bug through a new stress testing methodology that we're working on. You may check a short description in the following link:

1) http://dl.acm.org/citation.cfm?doid=2628194.2628201

Basically, this methodology is based on two testing campaigns that we carried out. You may find them in the following links:

1) https://seer.lcc.ufmg.br/index.php/jidm/article/view/249
2) https://seer.lcc.ufmg.br/index.php/jidm/article/view/250

Best regards,

Edson Ramiro