[
https://issues.apache.org/jira/browse/QPID-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Moravec updated QPID-5121:
--------------------------------
Attachment: QPID-5121.patch
The function wrfc::enq_threshold does not calculate with the use case of
enqueue bigger than the journal size. Its return value/formula is fine but
"in_use" is wrong for the use case.
Hence the change in code - when findex ( circulating from _fc_index in "ring"
from 0 to _lpmp->num_jfiles()-1 ) reaches again _fc_index, let mark the current
journal file as "in_use".
Also it makes some sense to extend:
while (fwd_dblks && !(findex != _fc_index && fcp->enqcnt()))
to
while (fwd_dblks && !(findex != _fc_index && (fcp->enqcnt() || in_use)))
just improve performance of the method for huge enqueue over tiny journal
(where redundant hundreds of loops over journal files are made). Anyway I would
vote against the change, as:
- it helps in one corner case but makes other cases less performant
- the corner case is really rare (who would use tiny journals for sending huge
messages there frequently?)
> Store module does not raise exception when attempting to enqueue a message
> bigger than the journal size
> -------------------------------------------------------------------------------------------------------
>
> Key: QPID-5121
> URL: https://issues.apache.org/jira/browse/QPID-5121
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.22
> Reporter: Pavel Moravec
> Attachments: QPID-5121.patch
>
>
> Description of problem:
> Whenever store module tries to write to a journal a message bigger than the
> journal capacity is, it a) does not store the message (so far so good), but
> b) it does _not_ raise an error (!!!). So the broker thinks the message was
> enqueued.
> That is a big gotcha, as the durable message is kept in memory only.
> Version-Release number of selected component (if applicable):
> 0.22
> How reproducible:
> 100%
> Steps to Reproduce:
> rm -rf /var/lib/qpidd/* /var/lib/qpidd/.* 2> /dev/null
> service qpidd restart
> # create a durable queue with tiny journal and send there one huge message
> qpid-send -a "DurableQueue4; {create:always, node:{durable:true, x-declare:{
> arguments:{'qpid.flow_stop_count':0, 'qpid.max_count':0, 'qpid.file_count':4,
> 'qpid.file_size':8, 'qpid.flow_resume_count':0, 'qpid.flow_stop_size':0,
> 'qpid.flow_resume_size':0, 'qpid.max_size':0 }}}}" -m 1
> --content-size=100000000 --durable=yes
> # check in stats the queue has the message enqueued
> qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn
> msgOut bytes bytesIn bytesOut cons bind
>
> =========================================================================================================================
> 7e553cc6-89d4-46b2-93fd-5ad7cf1f72a9:0.0 Y Y 0 0
> 0 0 0 0 1 2
> DurableQueue4 Y 1 1
> 0 100m 100m 0 0 1
> # restart the broker and check queue stats
> service qpidd restart
> qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn
> msgOut bytes bytesIn bytesOut cons bind
>
> =========================================================================================================================
> DurableQueue4 Y 0 0
> 0 0 0 0 0 1
> cddddd53-5b98-4101-ad35-de71e038cd61:0.0 Y Y 0 0
> 0 0 0 0 1 2
> # ouch, where the _durable_ message went to???
> Actual results:
> 1) generic reproducer for regular durable queue:
> - qpid-send/broker/store has not returned an error (THIS is the wrong)
> - after the broker restart, the queue has no message (this should be ok but
> not after no error raised)
> Expected results:
> qpid-send should fail due to "Enqueue capacity threshold" error (and no
> message should be kept in the broker later on).
> Additional info:
> - Optional/variant scenarios: send first some tiny message to the journal and
> then the huge one.
> - Trivial patch to be added
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
