RabbitMQ Java Client

lp:~tcole/rabbitmq-java-client/trunk

Created by Tim Cole on 2011-02-03 and last modified on 2011-02-03

Get this branch:: bzr branch lp:~tcole/rabbitmq-java-client/trunk

Related bugs

Link a bug report

Related blueprints

Branch information

Owner:: Tim Cole

Project:: RabbitMQ Java Client

Status:: Development

Import details

Import Status: Failed

The import has been suspended because it failed 5 or more times in succession.

Last successful import was on 2011-02-03.

Import started on 2011-02-07 on neumayer and finished on 2011-02-07 taking 2 minutes — see the log

Import started on 2011-02-05 on pear and finished on 2011-02-05 taking 1 minute — see the log

Import started on 2011-02-04 on galapagos and finished on 2011-02-04 taking 3 minutes — see the log

Import started on 2011-02-04 on neumayer and finished on 2011-02-04 taking 2 minutes — see the log

Recent revisions

252. By Steve Powell <email address hidden> on 2011-02-02

Factor out common sequence for channel.close in ChannelN.processAsync()

251. By Steve Powell <email address hidden> on 2011-02-02

Merge default

250. By Steve Powell <email address hidden> on 2011-01-28

Ensure notifyOutstandingRpc() is inside synchronised block.

249. By Steve Powell <email address hidden> on 2011-01-28

Delay notifyOutstandingRpc() until after responding to channel.close errors.

248. By Steve Powell <email address hidden> on 2011-01-27

Merging default

247. By Steve Powell <email address hidden> on 2011-01-26

Factored out asyncShutdown() from processAsync().

246. By Steve Powell <email address hidden> on 2011-01-26

Added channel.close response processing even if !isOpen()

o copied handling code in ChannelN.processAsync() to !isOpen() case
o improved atomicity of operations in shutdown processing
o spelling and comment adjustments

245. By Steve Powell <email address hidden> on 2011-01-18

Merged bug19112 (put generated java source into sources jar in maven build)

244. By Matthias Radestock <email address hidden> on 2011-01-17

a neater way to deal with multi-confirms

243. By Matthias Radestock <email address hidden> on 2011-01-17

fix logic bug in handling of multi-confirms
The code was assuming that there would be a contiguous sequence
between the first pending confirm and the received confirm, which
isn't the case since previous confirms can have punched holes into
that sequence.

Branch metadata

Branch format:: Branch format 7

Repository format:: Bazaar repository format 2a (needs bzr 1.16 or later)

This branch contains Public information

Everyone can see this information.

Subscribers

Tim Cole