The linkDown trap description states:
"A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state).
This other state is indicated by the included value of ifOperStatus."
Does it mean LINKDOWN alert would be notified after they go up ? Not at the moment that they go into down status ?
That wording doesn't match the wording in the most recent version of the IF-MIB, which is the best source:
DESCRIPTION "A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus."
Note that in the above it says the agent should send it when the link is about to go down.
However, I think you'll find most agent's don't necessarily support it that way very well. And the notification may only get sent after it goes down. It's nice in theory to think the above is the way it can be done, but picture a link going down because someone pulls the cable. It doesn't matter if the kernel is about to set it as "down". It still can't deliver a message over it, and functionally it's already down.
However, if the receiving management station is connected via another link, it'll still get the notification.
Related
I've written a basic rpc client which polls the state of an Solana account to look for a specific condition (i.e. a unique int64 Id being written to it). When the condition arises, I call a smart contract which takes the same account as a mutable argument.
Before doing anything, the program checks for the same condition. However this check fails. I understand we're dealing with a distributed system and that state maybe inconsistent for a period of time, but I can repeatedly call for over 30 secs and it fails each time, before ultimately succeeding.
I've read about the concept of commitment levels but always assumed the account state passed into the smart contract would be the latest state of the world (i.e. processed)? What I appear to be observing is it's more like the finalised state.
Can anyone shed some light on what might be going on here?
I will try and come up with a minimal code example to demonstrate the problem but just wanted to ask the question first, to see if anyone can point me in the right direction.
Thanks
So if you look at the docs you linked, processed has a note:
the block may still be skipped by the cluster
This is a very important note if you're only looking for account state changes and don't want some that may be false. There's a number of reasons that a slot can be skipped, or a transaction could be rejected by the cluster.
If any of the above happens, then the account state that is accepted by the cluster as a whole may not be reflected in processed, but finalized.
In the end my specific problem came down to pre-flight checks using the 'finalized' commitment level when my logic for polling the account was using 'confirmed'. Modifying the preflightCommitment argument on sendTransaction fixed the problem for me.
love the elsa-workflows project as I was heavily using WWF in the past. However many of my workflows where state machines. I can't see any in elsa, any plans to support this ?
Elsa 2 does not support the state machine model (only the flowchart model), but I am planning on revising the engine for Elsa 3 which would allow any type of model, including state machine and simple sequential flows like we have in Windows WF.
UPDATE
After I answered with the above I started to think ahead of the state machine architecture for V3, during which I realized we can implement the state machine model already today with V2.
All it would take is a simple new activity called e.g. "State" that has an infinite number of outcomes. This State activity would simply set a workflow variable called e.g. "StateMachineState" or "CurrentState". Each outbound connection would be connected to any trigger responsible for transitioning into the next state. This could be a message from a service bus, a timer, an HTTP request, or anything else that's available with Elsa.
The only real change that would need to be added to make the user experience smooth is the ability to keep adding connections without having to specify them manually from the activity editor. With the current design, we could probably just automatically add an extra outcome to the activity. So initially there would just be e.g. "Transition 1". When that one becomes connected, a "Transition 2" would appear.
Anyway, I am revising my answer to: it's not here yet, but:
You can implement it yourself today, and
I will add an initial version of the State machine model to either Elsa 2.1 or 2.2, depending on any hidden gotchas I might have failed to see.
UPDATE 2
I just pushed a change that includes a State activity.
With this, you can now easily implement a state machine by adding State activities to your workflow. Here's an example of a traffic light state machine:
This workflow kick starts automatically after 5 seconds, after which it will transition into the "Green" state. Then it stays there for 10 seconds before transitioning into the "Yellow" state. After 5 seconds, it then transitions into the "Red" state, and finally transitions back to the "Green" state after 5 seconds. Then it repeats.
To use the State activity, you specify things:
State name.
Allowed transitions (the traffic light example includes only one transition per state, but you can specify more than just one).
I am new to AMQP trying to understand the concept so my question might be very naive.
I am sending message to ActiveMQ Broker and while sending the message, I have to mention LinkName but that doesn't matter what I am putting at consumer side and producer side I am receiving the data anyway.
I am confused what is the deal with LinkName?
I can't really state it any better than section 2.6.1 of the AMQP 1.0 specification:
2.6.1 Naming A Link
Links are named so that they can be recovered when communication is interrupted. Link names MUST uniquely identify the link amongst all links of the same direction between the two participating containers. Link names are only used when attaching a link, so they can be arbitrarily long without a significant penalty.
A link’s name uniquely identifies the link from the container of the source to the container of the target node, i.e., if the container of the source node is A, and the container of the target node is B, the link can be globally identified by the (ordered) tuple (A,B,<name>). Consequently, a link can only be active in one connection at a time. If an attempt is made to attach the link subsequently when it is not suspended, then the link can be ’stolen’, i.e., the second attach succeeds and the first attach MUST then be closed with a link error of stolen. This behavior ensures that in the event of a connection failure occurring and being noticed by one party, that re-establishment has the desired effect.
From the ads api doc it says
effective_status enum {ACTIVE, PAUSED, DELETED, PENDING_REVIEW,
DISAPPROVED, PREAPPROVED, PENDING_BILLING_INFO, CAMPAIGN_PAUSED,
ARCHIVED, ADSET_PAUSED} The effective status of the ad. The status
could be effective either because of its own status, or the status of
its parent units.
status enum {ACTIVE, PAUSED, DELETED, ARCHIVED} The configured status
of the ad. The field returns the same value as 'configured_status',
and is the suggested one to use.
BUT, the problem is unless the advertiser actively stops or pauses or deletes an advert or campaign the ad's status is always (as far as I can see in the aforementioned cases) ACTIVE. Am I wrong?
Secondly, does anyone know what the column on the Ads manager interface called "Delivery" is? It has values like "Completed" , "Not Delivering" etc.
Is there any way I can get this information from the API?
The field called 'delivery' in Facebook's UI is not a single field returned by the UI, but is based on examining the status, start/end dates, etc of the ads–you could replicate this yourself by examining the ads and their parent objects.
I'm not sure I understand what you're saying about "configured and effective status": if an ad was paused, both its effective and configured status should be PAUSED. If, for example, an ad's Ad Set was set to paused, the ad's configured status would remain ACTIVE but its effective status would be ADSET_PAUSED.
How is the status computed?
When you give an Ad a status via the API you are setting its configured_status. This will update to whatever status you give it ACTIVE, PAUSED, etc.. And this value should reflect immediately in the configured_status parameter via a GET request to the object. The configured_status parameter will show whatever value you last set it too regardless of the parent status.
With that being said, if you have an ACTIVE ad that is nested under a PAUSED adset it will inherit the PAUSED status and that will reflect via the effective_status parameter. You can update the status of an Ad regardless of the status of the adset. It will only inherit the status if the parent is PAUSED to prevent spending.
As status will inherit from the parent object, it is most likely disabled. The effective_status reflects the current status of the object which may be overridden by its parent. More info can be found here
NOTE: I just posted the documentation for the Ad object but this applies to Adset objects as well
The configured_status is synonymous to the status parameter and is what you should set when updating the Ad.
About what the column on the Ads manager interface called "Delivery" is?
According to Facebook, the new feature identifies under-delivering ad sets and explains why the under-delivery is happening and highlights suggestions for specific actions an advertiser can take to make their ad more competitive at auction – in-turn helping them to increase the performance of their advert.
Advertisers can find feedback relating to their ads in the “Delivery” column at the campaign and ad set level, and also under the “Tools” standalone tab in Facebook Ads Manager.
Check these article this might help you to give insights into "Delivery":
In Facebook Power editor
In Facebook Ads Manager
P.S Some things you only learn by practicing and trying during development process you cannot always depend on Documentation.
Hope this helps!!!!
I'm trying to model a 'Social Care Alarm' service to see how it could map into the functionality of FHIR. A Social Care Alarm is basically an alarm button that a person wears at home, which when pressed (or when triggered by a fall sensor), sends a message to a central server where an operator calls the person who triggered the alarm.
The voice is obviously out of the scope, but could I do an 'alarm button', possibly also with geo-location? Would it be an Observation resource? The operator would typically have a web interface, with a list of triggered alarms. They'd then be able to clear the alarms, removing them from the list (but they'd be in the history).
This sounds like a Communication resource (from DSTU 2). To clear it from the list, the user would update the Communication to note that it had been received. The Communication would point to or contain the information to be conveyed, which could include geolocation.