public interface Receiver extends Link
Modifier and Type | Method and Description |
---|---|
boolean |
advance()
Attempts to advance the current delivery.
|
void |
drain(int credit) |
boolean |
draining() |
void |
flow(int credits)
Adds the specified number of credits.
|
int |
recv(byte[] bytes,
int offset,
int size)
Receive message data for the current delivery.
|
void |
setDrain(boolean drain) |
current, delivery, delivery, detach, detached, drained, getCredit, getDrain, getName, getProperties, getQueued, getReceiverSettleMode, getRemoteCredit, getRemoteProperties, getRemoteReceiverSettleMode, getRemoteSenderSettleMode, getRemoteSource, getRemoteTarget, getSenderSettleMode, getSession, getSource, getTarget, getUnsettled, head, next, setProperties, setReceiverSettleMode, setRemoteSenderSettleMode, setSenderSettleMode, setSource, setTarget
close, free, getCondition, getContext, getLocalState, getRemoteCondition, getRemoteState, open, setCondition, setContext
attachments
void flow(int credits)
credits
more deliveries.int recv(byte[] bytes, int offset, int size)
Delivery.isPartial()
. If
the delivery is partial, the caller should call recv(byte[], int, int)
again to receive
the additional bytes once the Delivery appears again on the Connection work-list.
TODO might the flags other than IO_WORK in DeliveryImpl also prevent the work list being pruned?
e.g. what if a slow JMS consumer receives a disposition frame containing state=RELEASED? This is not IO_WORK.bytes
- the destination array where the message data is writtenoffset
- index in the array to start writing data atsize
- the maximum number of bytes to writeLink.current()
void drain(int credit)
boolean advance()
boolean draining()
void setDrain(boolean drain)
Copyright © 2016 The Apache Software Foundation. All rights reserved.