You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org> on 2010/01/29 21:14:34 UTC
[jira] Updated: (QPID-1440) [Java Client] - Tidy up tasks from
QPID-1289
[ https://issues.apache.org/jira/browse/QPID-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell updated QPID-1440:
---------------------------------
Affects Version/s: 0.5
Fix Version/s: 0.6
> [Java Client] - Tidy up tasks from QPID-1289
> --------------------------------------------
>
> Key: QPID-1440
> URL: https://issues.apache.org/jira/browse/QPID-1440
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Client
> Affects Versions: M4, 0.5
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Priority: Minor
> Fix For: 0.6
>
>
> Review points from QPID-1289:
> AMQSession.java : _defaultPrefetchHighMark; _defaultPrefetchLowMark; should probably have the word "default" removed from their name
> AMQConnection.java: protected int _maxPrefetch; ... protected member varibales are (in general) evil... what is the justification for this over using getters/setters?
> ClientProperties.java: + public static final String MAX_PREFETCH_DEFAULT = "5000"; What is the reason for making the already large (1000) default even larger? The JIRA text above says make it 500
> XAConnectionImpl.java: + return _delegate.createXASession(_maxPrefetch, _maxPrefetch / 2); Why put this logic in the XAConnectionImpl? Surely we should have a method on the underlying connection which takes no arguments - and it can work out the default prefetch values?
> StreamMessageTest.java:
> - consumerSession.createConsumer(queue, AMQSession.DEFAULT_PREFETCH_LOW_MARK,
> - AMQSession.DEFAULT_PREFETCH_HIGH_MARK, false, false, (String) null, ft);
> + consumerSession.createConsumer(queue, Integer.parseInt(ClientProperties.MAX_PREFETCH_DEFAULT), Integer.parseInt(ClientProperties.MAX_PREFETCH_DEFAULT), false, false, (String) null, ft);
> This seems like a change in the test... what it really seems to suggest is that there should be a "createConsumer" method where you don't have to pass this in... since we clearly do not care about it in this instance, and we are having to repeat code that should be elsewhere (getting the defaults from client properties)
> ReturnUnroutableMandatoryMessageTest.java : same comment as for Stream message test
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org