I know a FT group name and transport. I need to discover how many active and inactive members does this FT group hold.
What options do I have?
Related
Let`s imagine we have server A with publisher and servers B and C with consumers.
Also we have got 5 different subjects; foo1, foo2,... foo5.
We always want to send a message only to one consumer and receive only one response.
So we utilize the requestOne function from the JS SDK at the publisher side and subscribe function with the {queue: "default"} option.
So both servers B and C has been subscribed one time for each subject.
But every time they subscribe they use queue with name "default" to prevent multiple consumers receive the same message as mentioned in docs.
So the question is:
Will this queue with name "default" be shared across all the subjects? Or each subject will have his own queue with name "default" and it is just shared between the subscribers of particular subject.
For example: producer generates 10 messages 2 for each subject.
Will we have 10 messages processed at the same time or only 2 messages since all the subscription share the same queue with name "default"?
You form a queue group based on the queue name that you specify and the subject. So a queue group of "foo" is different than a queue group on "bar".
That being said, with wildcards, you could have multiple subjects being part of the same queue group. That is, 2 members of the group "bar" listening on "foo.*" would split processing of messages sent on "foo.bar", "foo.baz", etc..
The same queue name in different subjects is separate.
You can test it with the examples in the link below.
https://nats.io/documentation/additional_documentation/nats-queueing/
start nats server
gnatsd
sub subject1
go run nats-qsub.go subject1 default
...
sub subject2
go run nats-qsub.go subject2 default
...
pub subject1&2
go run nats-pub.go subject1 "message"
...
go run nats-pub.go subject2 "message"
...
Can Instances in the same security groups in Amazon VPC can communicate each other any how
Instances associated with the same security group can’t talk to each other unless you add rules allowing it (with the exception being the default security group). you have to add rules to make them able to communicate.
It depends on the rules. The fact that two or more instances are associated with the same security group is not related to the allowed traffic.
Security groups is a set of allowed traffic rules, while the reference point is the instances themselves (meaning incoming traffic into the instance or outgoing traffic from the instance).
The definition whether instances have access to each others depends on the security groups' rules and the network ACLs' rules.
The communication will not be blocked as long there are rules that allow it.
A communication can be RDP, ICMP, HTTP/S and more, but it should be allowed in both security groups and NACLs.
A note to remember: by default, AWS blocks ICMP communication (ping), therefore, although the security group may have "All Traffic" allowed rule a ping request will fail if there is no specific rule that allows it.
Rules to connect to instances from an instance with the same security group
To allow instances that are associated with the same security group to communicate with each other, you must explicitly add rules for this.
The following table describes the inbound rule for a security group that enables associated instances to communicate with each other. The rule allows all types of traffic.
Protocol type
Protocol number
Ports
Source IP
-1 (All)
-1 (All)
-1 (All)
The ID of the security group
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html
Security Group name used in Source & Destination of FireWall rules
To create Security Group, we need to specify the FireWalled type of Inbound and Outbound rules.
Each Rule consists of Protocol, port number and Source (for inbound) or Destination (for outbound) IP addresses that are allowed, not denied.
But why is it that we can indicate Source or Destination as the name of a Security Group?
We do that because we want to refer to the IP addresses (for Source or Destination) of another appliance/instance which are associated with that specific Security Group. [Some people say these appliance/instance is in that specific Security Group]. But specifying Security Group or IP address is one thing. For communication to be successful, the allowed protocol and port number should be explicitly stated in the rule as well.
I am using a recent build of Torque/Maui (w/ PBS) to schedule jobs on a cluster with heterogenous hardware. Hardware consists on two set of 10 nodes for which I would like to have two group have elevated priority on one of the sets of nodes. For example:
Node set A of 10 nodes has elevated priority for User Group 1
Node set B of 10 nodes has elevated priority for User Group 2
I am familiar with how this is accomplished for all nodes, which is documented here:
http://docs.adaptivecomputing.com/maui/5.1.3priorityusage.php
However, I am unfamiliar on the best strategy to set this type of priority on a subset of the cluster. From what I can ascertain from the Maui docs it may be done using node sets or partitions, but I am unsure if either of these are correct or there is another strategy all together.
Edit: I would prefer to have a single queue as it simplifies usability and would enable a user to potentially use the entire cluster, albeit with differing priority on node set A and B.
Thanks in advance for the help.
The way I understand the question, you've confused node allocation with job priority. Job priority determines how much more quickly Maui will run a job, as it accrues priority in the priority reservation queue. This will determine how soon a job can run, within the constraints placed on the job, relative to all other jobs in the eligible/idle queue.
That's separate from where Maui decides to place (schedule) jobs. The most natural way to handle this type of use case is with standing reservations. You can create reservations over each set of nodes (via host list, feature, or partition), and then give both groups (or everyone) access to both reservations, but apply negative affinity to everyone outside the group with preferential access.
Example:
SRCFG[rsvA] NODEFEATURES=setA
SRCFG[rsvA] GROUPLIST=group1,ALL-
SRCFG[rsvA] HOSTLIST=ALL
SRCFG[rsvB] NODEFEATURES=setB
SRCFG[rsvB] GROUPLIST=group2,ALL-
SRCFG[rsvB] HOSTLIST=ALL
With this configuration, Maui will create reservation rsvA to include only the nodes with the "setA" property/feature, and jobs from group1 will gravitate (i.e., have positive affinity) to the nodes in that reservation. Likewise, jobs from users in group2 will flow to the nodes in rsvB, with the "setB" property (as defined in the nodes file, or on NODECFG lines in the maui.cfg). This configuration works fine with a single queue, and is essentially user-transparent.
I am new to this field of programming. I want to set up a system where there will be one client who is subscribed to the two multicast groups. I am using the below code to do this for one client subscribed to one group. Can any one help me how to add this client to another group for setsockopt like this?
group.imr_multiaddr.s_addr = inet_addr("226.1.1.1");
group.imr_interface.s_addr = inet_addr("192.168.1.9");
if(setsockopt(sd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&group, sizeof(group)) < 0)
{
perror("Adding multicast group error");
close(sd);
exit(1);
}
Note that the option is called IP_ADD_MEMBERSHIP. Just repeat what you already have for another group. A socket can join several groups. The limit is rather low but it is greater than one,
My program will take a list of multicast addresses and will join those multicast groups. Later on, the list of addresses may include new multicast addresses. Existing multicast addresses won't be deleted. As a requirement for my program, I cannot interrupt current multicast streams (so I cannot send a "leave" message). I had planned to cycle through list and send join messages to the multicast addresses in my list, without tracking which groups I've already joined. Is this OK?
I saw the post about sending join messages when receiving a Membership Query, but in this instance, I'm not responding to a Membership Query report.
You can join a group multiple times, if that's what you mean. Your description isn't clear. But I don't see what's so hard about knowing which groups are new and which are already current.
The Membership Query message is for UDP and routers, not for applications.