You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In v6.3.3 (current at the moment), the FormatPeekCommand method the peek command is formatted using Format(SqlConstants.PeekText, qualifiedTableName, maxRecordsToPeek), but in SqlConstants the peek text being formatted is SELECT isnull(cast(max([RowVersion]) - min([RowVersion]) + 1 AS int), 0) Id FROM {0} WITH (nolock) which does not include a {1}. So the value returned will always be roughly the number of messages in the queue, regardless of queue peek settings.
The assumption was probably that queue peek settings would be the maximum returned by the peek query, but the query was changed in this commit from SELECT count(*) Id FROM (SELECT TOP {1} * FROM {0} WITH (READPAST)) as count_table; because it has much better performance.
In the MessagePump class (in V7 this will be renamed to MessageReceiver) the message count is used as a ceiling for maximumConcurrentReceives but since the peek options are not honored, this will always be the approximate size of the queue, without regard for the queue peek limit. While the concurrencyLimiter does ensure that the endpoint concurrency settings are respected, the queue peek limit is not.
The text was updated successfully, but these errors were encountered:
The documentation for SQL Transport Design mentions queue peek settings, but these settings don't currently work. Further, the situation described in the blog post for the feature doesn't actually work either.
In v6.3.3 (current at the moment), the FormatPeekCommand method the peek command is formatted using
Format(SqlConstants.PeekText, qualifiedTableName, maxRecordsToPeek)
, but in SqlConstants the peek text being formatted isSELECT isnull(cast(max([RowVersion]) - min([RowVersion]) + 1 AS int), 0) Id FROM {0} WITH (nolock)
which does not include a{1}
. So the value returned will always be roughly the number of messages in the queue, regardless of queue peek settings.The assumption was probably that queue peek settings would be the maximum returned by the peek query, but the query was changed in this commit from
SELECT count(*) Id FROM (SELECT TOP {1} * FROM {0} WITH (READPAST)) as count_table;
because it has much better performance.In the MessagePump class (in V7 this will be renamed to MessageReceiver) the message count is used as a ceiling for
maximumConcurrentReceives
but since the peek options are not honored, this will always be the approximate size of the queue, without regard for the queue peek limit. While theconcurrencyLimiter
does ensure that the endpoint concurrency settings are respected, the queue peek limit is not.The text was updated successfully, but these errors were encountered: