I need to use a client library which support transaction in Kafka. I know that Java has transaction APIs to support transaction but I will prefer if these APIs would be available in Go. Please let me know if we have any stable library which I can use to write into multiple partition atomically.
I don't believe this is currently available. The librdkafka library is being updated currently to support it, and then from there the golang client will too.
Related
Using google i found two possible solution for now:
-using spring boot with kotlin
-using this kotlin client https://github.com/jillesvangurp/kt-search
I've already finished the android client application in kotlin but now i have to find a way to make this client comunicate with elasticsearch.
What would it be the best solution for my problem that i could look up online
Thanks in advance
First, if you don't use Spring in the current application, integrating it (if possible) would be a lot of work and most likely not worth it.
Another alternative would be to use the officially supported Java client for Elasticsearch (https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/current/index.html).
BUT, you should keep in mind that, if you put the Elasticsearch client in your client application, that the credentials, you may use, will also be in the client application.
They could be accessible for everyone using the Android client and the user could perform any request on the Elasticsearch. Also you couldn't change them without updating the client.
So, it is likely better to use a Three-Tier-Architecture (https://www.ibm.com/topics/three-tier-architecture) and creating an API service to handle the Elasticsearch requests.
I am using the library com.azure.spring:azure-spring-boot-starter-servicebus-jms:3.14.0 and I am trying to avoid the usage of a connection string by using a managed identity, but I wasn't able to find anything related on the internet. I also examined the library and I haven't seen any support for TokenCredential what Microsoft usually supports.
So the question is whether it is currently supported by the library or not?
In short, no.
The JMS API itself has no support for a "managed identity" or any kind of TokenCredetial object.
The JMS client implementation used here is Qpid JMS and it also has no support for a "managed identity" or any kind of TokenCredetial object.
I am investigating solution to implement microservice Saga pattern in platform hosted in K8S in GCP.
There are 2 options: Eventulate Tram and Axon. However, these frameworks seem not to support message broker managed by cloud provider such as google-cloud-Pubsub whereas I do not want to deploy either Kafka or RabbitMQ to K8S since GCP support PubSub already.
So is there any way to integrate either Eventulate or Axon to use google cloud PubSub?
Thanks
Uncertain about Eventuate's angle on this, but Axon works with extensions as message brokers other than Axon Server. Throughout Axon's lifecycle (read: last 10 years), some of these have been provided, but none are currently used for all types of messages defined by Axon Framework. So, you wouldn't be able to use Kafka for sending commands in Axon for example.
Reasoning for this? Commands, events and queries have different routing requirements which should be reflected by using the right tool for the job.
To be a bit more specific on Axon's side, the following extensions can be used for distributing your messages:
AMQP -> for Events
Kafka -> for Events
JGroups -> for Commands
Spring Cloud Discovery -> for Commands
As you can tell, there currently is no Pub/Sub extension out there to allow you to distribute your messages. Added on top of that, my gut would tell me if it was available, then it would likely only be used for Event messages due to Pub/Sub's intent when it comes to being a message broker.
Luckily this actually makes it rather straightforward to create just such a extension yourself. Going into all the details to build this would be a little much, so I would recommend to have a look at Axon's AMQP extension first when it comes to achieving this. Hints on the matter are that for publication, you should add a component to handle Axon's events and publish them on Pub/Sub. For handling events, you are required to build a StreamableMessageSource or SubscribableMessageSource. These interfaces are used respectively by the TrackingEventProcessor and SubscribingEventProcessor, which in turn are the component in charge of dealing with the technical aspect of handling events.
By the way, if you would be building such an extension and you need a hand, it would be best to request this at AxonIQ forum, which you can find here.
Last note, and rather important I'd say, is the argument that such a connector would not be able to deal with all types of messages. If you would require a more full fledged Axon application to run in a distributed fashion, I would highly recommend to give Axon Server a try prior to building your own solution from the ground up.
Does anybody has an example how to connect ActiveMQ OpenWire protocol using go please?
I used stomp & amqp with ActiveMQ for now and both are ok (testing), but our it architect will probably push for OpenWire as almost all our applications are Java based and that is standard for our company. So I would be happy for nay example, suggestions how to do it and not loose go service only because OpenWire protocol
thanks
Take a look at the ActiveMQ OpenWire documentation. It has a link to a handful of Java classes which are used to generate C, C#, C++, & Java client code. You could probably use those as examples to create your own files to generate Go client code which can speak OpenWire.
That said, you're probably better served by using the Go AMQP or STOMP clients as ActiveMQ was designed to be used by multiple protocols.
Thank you for answers. I agree with stomp & amqp as sufficient for task and agree that write OpenWire client just for sake of it is not good option. I have to convince our architects now
AMQP and OpenWire clients can co-exist and is by far the best solution for you, even though you have a Java-stack.
Your second best bet is to write some glue code in Java/C#/C++ that connects an OpenWire AMQ client with something that GO can speak to (like another ActiveMQ using AMQP or STOMP ;-) ).
If you really really really need OpenWire support, the best bet is to try to use the C++ client and call it using swig or whatnot.
Writing a native OpenWire-client in Go is a major effort and there is no point, except as a "fun" task.
Can clients using v5.10.2 client jar files connect to an ActiveMQ v5.15.5 server?
Based on my research they will both follow the JMS v1.1 spec and so should work, though obviously missing out on some of the improvements in the newer version.
The use case is clients running older versions of Java and therefore limited to older client jar files.
Note: this implicitly answers the question but as it's not explicit am leaving my question here for somebody authoritative to answer explicitly.
JMS is not a protocol it is an API specification.
ActiveMQ client's use the OpenWire protocol which does offer cross version compatibility so Older 5.x clients should work with newer 5.x brokers. That said the combinations aren't tested so while in theory it can work in practice it is best to upgrade the clients along with the broker whenever possible.