Release Notes Draft

1) Ability to specify "application/json" and HttpTextResponse working with swagger

QBit now support specifying the contentType. The default contentType is "application/json".

    @RequestMapping(value = "/hello8", contentType = "application/xml", code = HttpStatus.CREATED)
    public void hello8(final Callback<HttpTextResponse> callback) {

        final HttpTextResponse response = HttpResponseBuilder
                .httpResponseBuilder()
                .setBody("<xml><hi>hello world</hi></xml>")
                .setCode(201).buildTextResponse();
        callback.returnThis(response);
    }

Swagger meta data generation now works with HttpTextResponse and HttpBinaryResponse. However if you use HttpTextResponse or HttpBinaryResponse there is no way to specify a response schema so generating clients might be suspect.

Related issues:

• https://github.com/advantageous/qbit/issues/517
• https://github.com/advantageous/qbit/issues/518
• https://github.com/advantageous/qbit/issues/474

2) Bug fix Scala integration

QBit now ignores Scala generated methods. Issue

3) Support @GET, @DELETE, @HEAD, @POST, @PUT

Support @GET, @DELETE, @HEAD, @POST, @PUT annotation in addition to @RequestMapping.

The new annotations works like @RequestMapping except they default to the corresponding HTTP methods by default.

Issue

3) If batching is set to 1, create a no batch queue

We created a new queue sender that does not do batching. This way if batching is set to 1 on the QueueBuilder, QBit create a no batch queue so that we are not creating arrays and keeping the GC busy.

Issue

4) Add support to make a blocking call to a non-blocking interface via a blocking get/Future operation

Let's say you have an service as follows:

    interface Foo {
        void getValue(Callback<Boolean> callback);
    }

    static class FooService implements Foo {

        @Override
        public void getValue(Callback<Boolean> callback) {
            callback.accept(true);
        }
    }

        serviceQueue = ServiceBuilder.serviceBuilder().setServiceObject(new FooService()).buildAndStartAll();
        foo = serviceQueue.createProxy(Foo.class);

The call is async but for a test or some other reason, you want to call it and get an immediate result (QBit goes out of its way to make everything async, but sometimes especially for testing, you want to make a synchronous call).

Now you can!

        final AsyncFutureCallback<Boolean> callback = AsyncFutureBuilder
                .asyncFutureBuilder().setSupportLatch(true).build(Boolean.class);

        foo.getValue(callback);

        ServiceProxyUtils.flushServiceProxy(foo);

        final Boolean result = callback.get();

        assertTrue(result);

Issue

5) Add debugging for non started queues and queues that are filling up

If you set these env variable or system properties,

    private final boolean checkStart = Sys.sysProp("QBIT_CHECK_START", false);
    private final int checkStartWarnEvery = Sys.sysProp("QBIT_CHECK_START_WARN_EVERY", 100);
    private final boolean checkQueueSize = Sys.sysProp("QBIT_CHECK_QUEUE_SIZE", false);
    private final int checkQueueSizeWarnIfOver = Sys.sysProp("QBIT_CHECK_QUEUE_SIZE_WARN_IF_OVER", 10);

Then QBit will check to see if a queue was started and issues warning if it was not started. You can leave this on and check every 100 times or you can check every time for debugging.

You can also instruct QBit to check for queues whose size are over a certain limit.

These setting are off by default and are mainly used during development to make sure you have setup QBit correctly.

You should not really use these outside of development as there is a performance cost to the checks.

Issue

6) Improved JMS support

Added support to detect when the connection is closed.

• Issue 510
• Issue 509

7) Document marking a service as unhealthy to the health system

Issue 526. Docs added to Health System Documents

Service marking itself unhealthy with the health system.

@RequestMapping(value = "/todo")
@Api(value = "/todo", consumes = "", description = "Todod")
public class TodoService {
...
    /**
     * Used to call the queue. This gets called when our service queue is empty or has reached its limit.
     */
    @QueueCallback({QueueCallbackType.LIMIT, QueueCallbackType.EMPTY, QueueCallbackType.IDLE})
    public void process() {
        reactor.process();
        this.jmsConnected = jmsConnectedRef.get();

        final ServiceQueue serviceQueue = ServiceContext.serviceContext().currentService();
        if (!jmsConnected) {
            serviceQueue.setFailing();
        } else {
                serviceQueue.recover();
        }
    }

The above checks to see if JMS is up. If it is not up, then this service fails. If JMS is up, then the service is marked as recovered. The two ways a service can fail is if it never checks in, or if it marks itself as failed.

Once a service is marked unhealthy. The health end points will report this status.

If you have local health end point check installed then this will show up as failed.

$ curl http://localhost:8090/__health -v 
*   Trying ::1...
* Connected to localhost (::1) port 8090 (#0)
> GET /__health HTTP/1.1
> Host: localhost:8090
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 500 SERVER ERROR
< Content-Type: application/json
< Content-Length: 6
< 
* Connection #0 to host localhost left intact
"fail"

The admin end point returns true 200 if ok and false 200 if not ok.

$ curl http://localhost:7779/__admin/ok -v
*   Trying ::1...
* Connected to localhost (::1) port 7779 (#0)
> GET /__admin/ok HTTP/1.1
> Host: localhost:7779
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 5
< 
* Connection #0 to host localhost left intact
false

Once the service recovers, in this case, it is able to connect to JMS again.

$ curl http://localhost:7779/__admin/ok -v
*   Trying ::1...
* Connected to localhost (::1) port 7779 (#0)
> GET /__admin/ok HTTP/1.1
> Host: localhost:7779
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 4
< 
* Connection #0 to host localhost left intact

true

$ curl http://localhost:8090/__health -v 
*   Trying ::1...
* Connected to localhost (::1) port 8090 (#0)
> GET /__health HTTP/1.1
> Host: localhost:8090
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 4
< 
* Connection #0 to host localhost left intact
"ok"

Then things go back to normal.

8) Added @PUT, @POST, @GET, @HEAD, and @DELETE annotations

We added some new annotations that work like @RequestMapping but lead to more terse annotation usage.

The @POST annotation changes the status code to HttpStatus.CREATED as an HTTP POST is a create or add operation while a PUT is a modify, edit, update operation.

@PUT, @POST, @GET, @HEAD, and @DELETE are used to annotated methods and work very much like @RequestMapping except the method is already set and in the case of @POST the HTTP Status code is changed to CREATED.

This was added to make the annotation more terse and it also is a bit more familiar to someone who is used to JAX-RS.