bloomberg / blazingmq-sdk-java Goto Github PK

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

From the logs you can see that toString is implemented to PushMessageAdapter only.

12:27:06,590 (main) ERROR SessionStressIT:267 Last PUT : com.bloomberg.bmq.Session$QueueAdapter$PutMessageAdapter@6b05a1fd
12:27:06,590 (main) ERROR SessionStressIT:268 Last ACK : com.bloomberg.bmq.Session$QueueAdapter$AckMessageAdapter@45ac5ad1
12:27:06,592 (main) ERROR SessionStressIT:269 Last PUSH: [ Queue URI: bmq://bmq.test.mmap.priority/java-it-cbc42d86-7c43-4f7c-8377-be88b7a06108 ][ PushHeader [ Flags=2 MessageWords=267 OptionsWords=2 CompressionType=0 HeaderWords=8 QueueId=0 MessageGUID=0003E7000002F90E62391B26CF840BF9 SchemaWireId=1 ] ][ PushMessage [ SubQueueIds [ [0] ] ][ Payload ["................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................***" ][ MessageProperties [ [ MessageProperty [ Type=STRING Name=routingId Value="abcd-efgh-ijkl" ] ][ MessageProperty [ Type=INT64 Name=timestamp Value=123456789 ] ] ] ] ]

Describe the solution you'd like

Implement toString for PutMessageAdapter and `AckMessageAdapter

Alternatives you considered

No response

BlossomQ -> BlazingMQ

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Currently, there is a lot of time spent copying payload data.

Especially onerous is an entire copy made just to generate a crc32c of the payload.

Using the pack() / flush() API should be be more efficient.

Also, ByteBufferOutputStream copies incoming ByteBuffer contents to "pack" the data. Instead, the incoming ByteBuffers can be appended as-is.

Expected Behavior

No response

Steps To Reproduce

put a high volume of messages into a queue while using Java Flight Recorder to profile the method execution times.

BlazingMQ Java SDK Version

0.0.9

Anything else?

No response

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

For native broker currently we have some ENV vars being set in the code, but these variables do not do anything right now, because we use static config. Here:

This means that currently we can use params listed in static config only, so storage path, logs path, broker port are the same for each launched broker. The last means that native IT brokers could only be launched on a default 30114 port, and no parallel ITs execution possible.

We create a TMP folder which should contain storage, logs etc, but we are not able to use it with a static config:

Expected Behavior

Native brokers in ITs should be able to use TMP folders and non-default parameters.

Steps To Reproduce

Launch ITs with -Dit.brokerDir=/path/to/native/broker

BlazingMQ Java SDK Version

0.0.10

Anything else?

No response

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

We have a lot of lines like this:

        logger.info("==============================================");
        logger.info("BEGIN Testing SessionIT queue flush down.");
        logger.info("==============================================");

We might want to standartize this to avoid errors.

Describe the solution you'd like

I propose to make a helper class for this, the usage should look like this:

class ComponentIT {

  public testStress() {

    TestScope scope = new TestScope(this, "testStress");
    // should log:
    // ==================================
    // #BEGIN_TEST ComponentIT testStress
    // ==================================

    scope.step("Open session");
    // should log:
    // #STEP 1. Open session

    scope.step("Close session");
    // should log:
    // #STEP 2. Close session

    scope.end();
    // should log:
    // ==========================================
    // #END_TEST ComponentIT testStress - 13.21 s
    // ==========================================

  }

}

Alternatives you considered

No response

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

If you log ByteBuffer[] generated by SchemaEventBuilder just before sending, you can see 2 buffers, one of these has limit==8 and capacity==4096. The event header is written to a separate buffer which is not used after this.

16:34:21,151 (pool-4-thread-1) ERROR RequestManager:319 java.nio.HeapByteBuffer[pos=0 lim=8 cap=4096]
16:34:21,151 (pool-4-thread-1) ERROR RequestManager:319 java.nio.HeapByteBuffer[pos=0 lim=228 cap=4096]
16:34:21,153 (pool-4-thread-1) INFO RequestManager:324 Message sent: Request message: {"rId":3,"openQueue":{"handleParameters":{"uri":"bmq://bmq.test.mem.fanout/java-it-5dfa06ed-f58c-40c0-ba70-9de9be753d77","qId":0,"subIdInfo":{"subId":2,"appId":"bar"},"flags":2,"readCount":1,"writeCount":0,"adminCount":0}}}; Timeout duration: PT20S

Expected Behavior

Will be good to use the same buffer for both event header and the event payload.

Steps To Reproduce

Log

BlazingMQ Java SDK Version

0.0.10

Anything else?

No response

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

I have been looking into the SDK and noticed that it is still using JUnit 4 for testing, considering that JUnit 5 is the current version with a lot of extensions, it would be great to migrate the tests to use the latest compatible version of JUnit for JDK8, JDK11 and JDK17.

Describe the solution you'd like

I would like to switch JUnit 4 to JUnit 5, following the guidelines from their official site, as well as update the version of the Mockito framework accordingly.

One of the possible approaches would be to use https://docs.openrewrite.org/running-recipes/popular-recipe-guides/migrate-from-junit-4-to-junit-5 as a recipe to quickly apply initial set of changes.

Alternatives you considered

No response

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

Commonly failing tests:

BrokerSessionIT.closeQueueOnPendingConfigureRequest:2890 expected:<SUCCESS> but was:<TIMEOUT>
BrokerSessionIT.inboundWatermarksTest:5621->verifyQueueControlEvent:187 Expected 'QueueControlEvent', received 'com.bloomberg.bmq.impl.events.BrokerSessionEvent'
SessionIT.testQueueFlushDown:3566 Runtime com.bloomberg.bmq.BMQException: Failed to start session: TIMEOUT

Describe the solution you'd like

Check timeouts, check multithreaded problems

Alternatives you considered

No response

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

Currently only docker ITs run available.
Native run might be helpful when we need to check custom-built broker with Java SDK.

Describe the solution you'd like

Switch between native/dockerized broker with maven properties.
Unification of properties needed, currently we have bmqBroker.nonDockerized and it.dockerImage properties. Will be good to have similar names.

Like this:

# docker ITs run
mvn -Dit.dockerImage=bmqbrkr:latest verify

# native ITs run
mvn -Dit.brokerDir=/usr/local/bin verify

Alternatives you considered

No response