I have Spring WebSockets configured and working. Clients subscribe to a specific topic (e.g. /topic/contract/contract_id) and whenever there's a message for that contract/topic, they receive it.
The issue is that certain types of messages being sent to this topic are sensitive and should only be received by some clients, but not others. So I need to analyze a message that's being sent when it's being sent, the clients that are subscribed to receive it, and let it through for some clients but not for others. Is there a way to do this in Spring WebSockets?
It sounds like you are using Pub/Sub pattern. I am no expert on Spring Web Sockets, but it sounds like a dilemma on a higher abstraction and not on the level of data transmission.
There are two things you can do:
Either disallow specific clients to subscribe to the channel at the first place, but it sounds like some messages are sent through, some are not. Hence I'd recommend the second option:
Maintain public (group like) and private channels.
In the first case just intercept the end point or service that is being called during subscription, and throw a Security exception or communicate somehow disallowed join.
In the second case, have a unique strong id for the channel name, that is known only to those who concerned, and they can listen to private messages.
I had experience with the second case and it worked perfectly, although we had no critical information as it was part of a game, so only one player can receive that message and not the group.
Related
I have an application built with the framework Axon 3.
There are 2 instances (jvm)
The first one handles commands and notifies the second one with RabbitMQ to construct a read model database.
There is an event store for this application (MongoDB)
Now I want to build a third instance and Is that possible to replay all historic events of the first instance via RabbitMQ to construct the initial state of the third instance ? and how to configure it ?
I tried the doc Axons for an answer, it seems that I should use TrackingEventProcessor instead of the default one SubscribingEventProcessor, but it does not allow to use with SpringAMQPMessageSource (mentioned in the doc)
Axon has two modes: Tracking and Subscribing. Depending on the source of your events, you can chose either one or sometimes both styles.
AMQP is a specification for a message broker. Once a message is delivered, it is removed from the Queue it was placed on. Therefore, conceptually, it is impossible to replay those events, since they don't exist in the broker anymore.
If replays are important, make sure you use a messaging mechanism that stores the messages. In Axon, the EventStore does exactly that. For now, Axon only has the EmbeddedEventStore, but you could have an Event Store in the receiving node point to the same database as the sending node.
At the moment, at AxonIQ, we are working on an Event Store Server, that deals with this in a cleaner way (no need to share datasources between instances).
I have an third-party application that puts some messages to JMS Queue.
Also I have an application that reads the messages from this queue. Depending on the type of the message I save this message to DB or send it to the third-party service. Also we shouldn't exceed some fixed calls per second limit not to overload the third-party.
Currently, two solutions came to my mind for this use case.
The first one is to ask the third party to send some custom headers, so that JMS consumer will be able to filter messages using JMS Selectors. So, in this case we'll be able to create two consumers, the first one will be able to read messages and save them to DB, and the second one will use some throttling/polling mechanism to send messages to third party at particular load.
But this approach won't work for me cause it will take ages for a third party to add those custom headers. Something like this in Camel:
from("jms:queue?selector=firstSelector")
.bean(dbSaver);
from("jms:queue?selector=secondSelector")
.throttle(10)
.bean(httpClient);
The second one is to create another two JMS Queues and a processor that will split the messages between these queues. Then goes the same logic as in first solution. However, this means that 2 extra JMS queues should be added. In Camel:
from("jms:parentQueue")
.choice()
.when(body().contains(...))
.to("jms:fistChildQueue")
.otherwise()
.to("jms:secondChildQueue")
.end()
from("jms:fistChildQueue")
.bean(dbSaver);
from("jms:secondChildQueue")
.throttle(10)
.bean(httpClient);
Also, I've been thinking of using two in-memory queues instead of JMS Queues. However, in this case if there'll be a lot of messages in JMS Queue we can easily get into troubles with memory.
Could anyone suggest an architectural design for this use case? It would be great to see it in Camel Route style.
1. Do you really need a queue for the flow to the DB? You could have bean(dbSaver) in the first route, or abstract it into a "direct" route instead of a jms-consuming route. This way, you have two queues instead of three.
2. A second approach: If you have control over the DB, you could write the second type of message to a different table. Then, an sql-consumer can poll for records, and delete them as it consumes them and passes them onward to the http service. However, the table is acting like a "roll your own Q". Probably more work for little payback, so maybe a second queue is better.
3. Finally, I wonder if you could reuse the same Queue. I see an option that will allow you to write back to the same queue. You could add a header and write back certain message. This could look confusing, and a bug could create an infinite loop.
If you already use JPA, this could be made a bit easier by using the camel-jpa component. As a consumer, it acts reads and deletes records (default behavior). I don't think the SQL/JDBC components have anything like that out of the box.
I have searched a lot on stackoverflow questions but I couldn't find the solution that fulfill my requirement; if any one known about reference that exactly match my requirement please comment otherwise answer it.
I am developing Enterprise application using Spring Framework in team, I have successfully integrate the "JMS" using ActiveMQ in application.
In this application User A send message to User B if user B is online otherwise not!
My Question is that how to check that User B session is live or not before user A message send to User B
Thanks In advance
Yasir Shabbir
it depends how you make communication with user B.
use web sockets to make push notifications to verify the status and push messages to user B.
client can regularly poll the server to get data if arrives from any user (in this case user A). if user B is online then only yhe polling can happen so it would be like user B gets a message from user A when he's online.
You need something that monitor the users http session.
The simple approach is to have a Map or Set. Put the usersId (or what ever you use to identify them) in that Map/Set when ever they login, also put hat Id in the Session. Then use a HttpSessionListener to get notified when ever a session get destroyed (that is the closest thing to SessionTimeOut you will get). When the Session gets destroyed the remove the userId from the Map/Set.
(BTW. there is a new Spring Project: Spring-Session, I did not have a look on it up to now. Maybe it contains support for that problem.)
An easy way if you have a small number of clients is to use request-reply over messaging in conjunction with topics. Have all user sessions listen to topic (pings or similar). When a client wants to see who is online, they send a message (the contents of the body don't matter) and set the JMSReplyTo and JMSCorrellationID headers to identify a temporary queue that they are listening to for replies. The listening parties will pick up this message and all send back a message containing their ids. That way you have a living cache on the sender as to who is currently "online", the cache should expire every couple of seconds.
Take a look at http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
I use ActiveMQ extensively throughout our application. It's a typical client/server application where the client displays a table of data that gets dynamically updated when something changes on the server. Currently the way we operate is the server subscribes for data request messages, the client subscribes for an initial load topic (data.client's ip address) and a generic data.updates topic. Then when the server receives a data request message it sends out an initial burst of "all data" to a client specific topic (something like data.ip address (this topic is specific to that one client)). Is there a better way to do this? It seems clumsy and verbose to have the "data request message", and the client specific topic.
One idea is to have the server subscribe for Advisory topics, that way the server will know when a client subscribes for an initialize topic like data.. This will get rid of the data request message.
Is there a better way to send an initial load of data to a client than with a "private topic"?
I wouldn't use JMS for this...you might consider using a REST service to retrieve the initial data from the system of record (relational database, etc.)...then use JMS Topics to track update events as you described
I think the better way is to turn this into a request/response type of message, either synchronous, or asynchronous.
I am trying to resolve a design difference of opinion where neither of us has experience with JMS.
We want to use JMS to communicate between a j2ee application and the stand-alone application when a new event occurs. We would be using a single point-to-point queue. Both sides are Java-based. The question is whether to send the event data itself in the JMS message body or to send a pointer to the data so that the stand-alone program can retrieve it. Details below.
I have a j2ee application that supports data entry of new and updated persons and related events. The person records and associated events are written to an Oracle database. There are also stand-alone, separate programs that contribute new person and event records to the database. When a new event occurs through any of 5-10 different application functions, I need to notify remote systems through an outbound interface using an industry-specific standard messaging protocol. The outbound interface has been designed as a stand-alone application to support scalability through asynchronous operation and by moving it to a separate server.
The j2ee application currently has most of the data in memory at the time the event is entered. The data would consist of approximately 6 different objects; a person object and some with multiple instances for an average size in the range of 3000 to 20,000 bytes. Some special cases could be many times this amount.
From a performance and reliability perspective, should I model the JMS message to pass all the data needed to create the interface message, or model the JMS message to contain record keys for the data and have the stand-alone Java application retrieve the data to create the interface message?
I wouldn't just focus on performance for the decision, but also on other non-functional considerations.
I've been working on a system where we decided to not send the data in the message, but rather the PK of the data in database. Our approach was closer to the command message pattern. Our choice was motivated by the following reasons:
Data size: we would store the data in BLOB because it could bu hughe. In your case, the size of the data probably fit in a message anayway.
Message loss: we planned for the worse. If the messages were lost, we could recover the data and we had a recovery procedure to resubmit the messages. Looks maybe paranoid, but here are two scenario that could lead to some message being lost: (1) queue is purged by mistake (2) an error occurs and messages can't be delivered for a long time. They go to the dead message queue (DMQ) which eventually reaches its limit and start discarding messages, if not configured correctly.
Monitoring: different messages/command could update the same row in database. That was easy to monitor and troubleshoot.
Using a JMS + database did however complicates a bit the design:
distributed transactions: this adds some complexity, and sometimes some problems. Distributed transactions have subtle differences with "regular" transactions, such as distributed timeout.
persitency: the code is less intuitive. Data must first be persisted to have the PK, which leads to some complexity in the code if an ORM is used.
I guess both approaches can work. I've described what led us to not send the data in the message, but your system and requirements might be different, so it might still be easier to send the data in the message in your case. I can not provide a definitive answer, but I hope it helps you make your decision.
Send the data, not the pointer. I wouldn't consider your messages to be an extraordinary size that can't be handled.
It will be no problem for the queue to handle the data, the messages in the queue are persisted anyway (memory, file or database persistence whatever fits better for the size of your queue).
If you just put a handle to the data in the queue the application that process the queue will make unnecessary work to get the data that the sender already has.
Depending on your question I cannot say what's the best in your case. Sure there are performance implications because of the message size and stuff, but first you need to know which information needs to be sent to the remote system by your message consumer, especially in a system which may have concurring updates on the same data.
It is relevant whether you need to keep the information stored in the remote system in sync with the version of the record just stored in your database, and whether you want to propagate a complete history along to the remote system which is updated by the message reciever. As a lot of time may pass in between the message send and the processing on the other end of the queue.
Assume (for some reason) there are a whole lot of messages in the queue, and within a few seconds or minutes three or four update notifications on the same object hit the queue. Assume the first message is processed after the fourth update to the record was finished, and its update notification is put in the queue. When you only pass along the ID of the record, all four messages would perform exactly the same operation on the remote system, which for one is absolutely superfluous. In addition, the remote system sees four updates, all the same,but has no information of the three intermediating states of the object, thus, the history, if relevant, is lost for this system.
Beside these semantic implications, technical reasons for passing the id or the whole data are whether it's cheaper to unwrap the updated information from the message body or to load them from the database. This depends on how you want to serialize/deserialize the contents. The message sizes you provided should be no problem for decent JMS implementation when you want to send the data along.
When serializing java objects into messages you need to hold the class format in sync between sender and consumer, and you have to empty the queue before you can update to a newer version of the class on the consuming site. Of course the same counts for database updates when you just pass along the id.
When you just send the ID to the consumer you will have additional database connections, this might also be relevant depending on the load on the database and how complex the queries are you need to execute to get the objects.