We use workshops to discuss design questions occuring within the Java Broker.

The following is a list of workshops for discussion:

How do we prevent a CO using another CO before it is ready?

(Highlighted by QPID-7160)

At what stages of the CO's lifecycle is it legal for other CO's to interact with it?  What if a CO need to perform some action once another CO has attained a certain state?

It seems we need some written rules of the road and possible some new state/future mechanics to allow a CO to perform an action once another object attains a certain state.

Managing Long running operations

(Highlighted by QPID-7172)

How does an operator manage a long running operation, for instance a purge queue?  The operator should be able to invoke the operation and then later return to it and check on its progress and know its outcome.

At the moment, a Jetty thread blocks whilst long running operations are in flight.  

As a user, I would want to be able to monitor a long running operation and know its result, even if I logged off and returned later.  We might consider making long running tasks cancellable too.

Maturing the REST API

Swagger

Use of range header

Backward compatibility.

Default depth / including children in the JSON

Omitting fields on update

Prevent Deletion of the objects that are in use

(QPID-7197)

At the moment we have repetitive code scatter throughout the implementation that verifies that an object that is about to be deleted is not in use.  We want to shift this responsibility to the core model.  There are a couple of options, one it outline on the Jira,

  • No labels