Re: Small arrays in rsrv

[Ralph Lange <Ralph.Lange@gmx.de>]

Update:

I spent the major part of two afternoons on this and decided to drop it.

While I was able to do the code changes on the part that pushes updates on the queue (in dbScan.c) with reasonable effort, the counterpart (the event_task pulling data from the queue) eventually calls dbGet() (in dbAccess.c) to get the data out.
That code is bad and fragile enough already, it is being called from different contexts, and I did not manage to add yet another layer of conditional execution without breaking or segfaulting or pulling zeros from the wrong place.

I would say this is in a state where adding another option would call for a 100% unit test followed by a refactoring and redesign.
Probably worth doing, but not a minor thing that goes between 3.15.1 and 3.15.2. Codeathon work?

As for my original use case, I found that rsrv is actually dropping updates in more than one place.

1. When pushing in the queue: a. If there is an update already on the queue for the same subscription, of the record-reference type, the new update is dropped. b. If the connection is in "flow control mode" or the queue is full, the last update in the queue is overwritten.
2. When pulling from the queue: if the connection is in "flow control mode", all updates are pulled and dropped except for the last one.

Allowing small arrays to be queued as-value would prevent dropping events under the first condition (1a.), but not in the other cases.

Cheers,
~Ralph

On 03/04/2015 21:27, Andrew Johnson wrote:

On 04/03/2015 11:12 AM, Michael Davidsaver wrote:

To be honest I'm slightly surprised that we haven't already done that.
I'd be in favour of the change Ralph is suggesting using the size, and I
would even suggest considering allowing the user to adjust how large the
log buffer is at initialization time. This would allow users to turn on
DB_EVENT_LOG_STRINGS (which nobody else really knows about anyway)
without recompiling.

Selecting the size at runtime might mean a more invasive change to
db_field_log.

True, but I'm encouraging Ralph to look at that further possibility as
well; we don't know for sure how much more complex it might be until
someone actually codes it (it might be as simple as adding an integer
variable and 2 additions).

A 3.15 change IMHO, as is Matej's pCAS update.

To me, depends on final complexity.

Agreed, I'm just suggesting that development be done on the 3.15 branch
as it's easier to merge a feature branch into a later release branch
than it is into an earlier one.

- Andrew