I'm new to Fast-RTPS.
I would like to use HelloWorldExampleTCP to run a publisher to publish messages to two subscribers. I started two subscribers node in pc1 and then start a publisher in pc0.
The expected result should be: both subscribers received messages sent from publisher.
But the actual result is, only one subscriber received the messages.
Any comment will be appreciated.
Kevin Kuei
The problem is the second subscriber doesn't get in time to receive the messages.
If I set -s 1000 in publisher, the second subscriber will receive the messages.
Kevin Kuei
Related
One process is producer of Bull queue(javascript) and 3 processes are consumer of the same queue.
Queued data by the producer process are paired and chronological order.
Each data object is like this : {order:1-1}, {order:1-2}, {order:2-1}, {order:2-2}.....
{order:1-1}, {order:1-2} data are paired ,and each data is in queuing chronological order.
It should also be dequeued chronologically.
If they are dequeued like {order:1-2}, {order:1-1}, it's useless.
When I run a single consumer process, dequeued data are chronological.
But, when the multi processes consume the queue, the dequeued data are not in the chronological order.
I think dequeued data by the multi processes are not FIFO.
It seems dequeued out of order.
So, I've tried to limit the process count to access queue at the moment.
I think the concurrency setting can be used for this.
const queue = new Qeueu('test', {
redis :{
host : 'localhost',
port : 6379
},
settings : {
concurrency : 1
}
But, the result is the same with before. Output of paired data are not in chronological order.
When I checked the queue status, the active count was 3.
It means that 3 queue was activated by the 3 process. My purpose is only one process access queue at the moment
I think that the concurrency setting is not working.
Or I'm applied incorrectly.
Here are summarizing my questions:
In the Bull queue(redis), are dequeued data not in chronological order if multi processes consume queue?
Or basically, it's not possible to keep chronological order in the multi processes because each process's processing time different. So, output will be out of order even though they read queued data in chronological order.
If so, is there any solution in chronological order?
How to set Bull queue if I want to make only one process can access the queue at the moment?
According to my investigation, Bull queue doesn't support in chronological order.
Single process or multi processes are the same result.
Instead of Bull queue, please use list if you want in chronological order.
It's working well with a single process and mutl processes.
I have 2 tables, first 'group' and second 'messages' and load messages from message table by group id and Paging library, My problem is every time new messages arrived from server and save in messages table Room notify LiveData data changed in table message and if for example I was open MessagesActivity for group 1, if new message arrive for group 2, because that added to messages table, room notify data updated (Which i don't want that).
So please help me:
Select * FROM messages WHERE groupId = 1
I need Room notify LiveData just if new message arrive for group which currently user open that
I want to test that 3000 users received the text messages I sent them from my product to them.
We are using Twilio multiple numbers (10) to speed up the delivery.
Now I want to test that when each user receives the text and if all 3000 users received it or not.
Basically, I am looking for a solution for fake numbers (at least 3000). So I can send the message to those test numbers and check the received messages as well.
I have a scenario where i need to get three different type of messages. They all contains same information. Lets take for e.g
I have 3 diffrent dealers of car Ford,Honda, Nissan.
They all send me message about car and its specs.
Would you create three queses
ABCCarCompany.E.Direct.Honda
ABCCarCompany.E.Direct.Nissan
ABCCarCompany.E.Direct.Ford
OR just one
ABCCarCompany.E.Direct.Cars
and have them send the car manufacturer as parameter..
What are pros of creating 3 queses vs 1 ..
I recommend that you send all data into a single exchange, call it CarEx. 1 vs 3 queues depends on how you want to use the data. If you need to do the exact same thing with each car that comes in (like put it in a database) then you only need one queue. If you need to do something different for each car (like put into a database for Ford but send an alert for Nissan) then you would want 3 different queues.
If you have 3 different queues you can route the messages into them based on the routing key.
I like this article: http://technet.microsoft.com/en-us/library/dd576261(v=sql.100).aspx because of the receive top (10000) into a table variable. Processing a table variable with 10000 messages would give me a giant boost in performance.
receive top (10000) message_type_name, message_body, conversation_handle<br>
from MySSBLabTestQueue<br>
into #receive
From reading, the receive provides messages given a single conversation_handle. I have 200+ stores all sending messages with the same message type and contract to the same server. Can I implement the server to get all the messages from these stores on a single call to receive?
Thanks
A target can consolidate multiple conversations into few conversation groups, using the MOVE CONVERSATION. The RECEIVE restricts the result set to one single conversation group so moving many individual conversation into a single group can result in bigger result sets, as you desire.
For the records, initiators can also consolidate conversations using MOVE CONVERSATION, there is nothing role specific here. But initiators can also use the RELATED_CONVERSATION_GROUP clause of BEGIN DIALOG to start the conversation directly in the desired group, achieving consolidation and thus bigger result sets w/o having to use MOVE. This is useful because you can simply reverse the roles in the app, ie. instead of stores starting the dialogs with central server, have the central server start the dialogs with each store (thus reversing the roles) and the central server can start the dialogs in as few conversation groups as it likes, even 1. This removes the need to issue MOVE CONVERSATION.