Feature/artemis rest api #665
Conversation
…ut through ActiveMQ Artemis utilizes Apache Camel with the AQAPI connection factory in order to hook into Oracle Queues and route to Artemis. TODOs: - determine artemis connection/port - determine which oracle queues to subscribe to - determine clientid/durable subscriber name - register artemis queues with swagger UI and standardize naming artemis architecture docs: https://activemq.apache.org/components/artemis/documentation/2.4.0/architecture.html
artemis starts up apache camel and uses an internal VM connection to artemis
There was a problem hiding this comment.
Overall, I like it. I'm pretty sure we'd go ActiveMQ if we need additional or more advanced MQ Support or just dropped Oracle and this seems to blend in nicely.
The Map vs Object is odd, honestly thought those would've been the same but maybe that's just an Oracle thing.
But otherwise it looks fairly clean and looking at broker.xml I assume the persistance can be pointed to other than a filesystem which would be necessary on CWBI but not for the T7s or testing/dev.
|
Haven't played with ActiveMQ in a while and was basically ignoring Artemis but definitely seems like they've done a good job with it. |
|
Only thing I'm not sure I like is that 503. A lack of message isn't a server problem, but it appears ActiveMQ did a little homework and didn't think anything else was suitable. |
|
I had the same thought on 503, hard for the client to determine if that error code is happening due to other server related issues or if it's just Artemis not getting a message yet. There is also the Accept-Wait header, but due to the low volume of messages we currently operate with, we'd still need to react to the 503's anyways. For answering persistence, there is documentation on using a database (Postgres, Derby, MySQL) https://activemq.apache.org/components/artemis/documentation/1.3.0/persistence.html instead of the file system. I believe we can stream the MapMessage object itself instead of mapping to JSON, however that means the client would need to deserialize as the AQ/JMS MapMessage implementation and that wouldn't work with non-Java. |
|
I like the idea of the conversion here. Let's us handle something more standard, it seems. But certainly something to note for later review. |
|
Well it looks like the Artemis REST API is dead: https://issues.apache.org/jira/browse/ARTEMIS-3987 and it is recommended to go the STOMP/STOMP-WS route instead. I'll start looking into that next. I had been looking at the 2.19.x documentation since that supported JDK 8. |
|
Well, that's unfortunate, and a bit surprising. |
This implementation bootstraps the artemis server within the same war deployment as the REST API.
documentation on the artemis REST API: https://activemq.apache.org/components/artemis/documentation/1.0.0/rest.html
Clients will need to do an initial HEAD/GET request against the queue/topic, then check the header for creating a subscriber. The REST API then becomes stateful as it is adding the subscriber. Then the client will get a unique URL pointing towards the next message. The client will need to continuously poll to check if there are new messages (503 error code if not).
The REST API only supports JMS Object and TextMessage types. Since the TS_STORED messages are of MapMessage type, I had to convert the map to JSON.
Proof of concept for java client via OkHttp: https://bitbucket.hecdev.net/projects/CWMS/repos/hec-cwms-data-access/pull-requests/199/diff#hec-db-radar%2Fsrc%2Fmain%2Fjava%2Fwcds%2Fdbi%2Fcwms%2Fradar%2FCwmsJmsCdaDao.java?t=209