What’s the meaning of “General variable binding error” in SNMP4J? - snmp

I use gettable to query some data successfully in one machine,but when I use the same command to query the other machine,it returns “General variable binding error”.How to fix it ? I can query the data in command line using Net-SNMP in the other machine.

That error message is defined in SnmpConstants.java as part of SNMP_ERROR_MESSAGES,
https://github.com/kaazing/snmp4j/blob/60518cb185e7738f94a9c754e85fa220afeffe6d/src/org/snmp4j/mp/SnmpConstants.java
You can see the error message is being used only in PDU.java,
https://github.com/kaazing/snmp4j/blob/60518cb185e7738f94a9c754e85fa220afeffe6d/src/org/snmp4j/PDU.java
and is only used when the SNMP response message has an error status of 5, aka GenErr.
That's unfortunately an ambiguous error reported by SNMP agents when they hit an exception that cannot be categorized to other error status.
So in your case,
try to use SNMP v2 to perform the queries and it usually gives a better error status code (v2 introduced more codes).
accept the fact that GenErr can happen and handle it (or ignore it).
Since it is an agent side behavior to return GenErr, you have no other option on the manager side.

Related

Does abigen generated code work on Quorum?

We use a fork of Quorum, and I'm trying to use Go code generated by abigen to call our contracts. I can dial and get the client, but every call so far has died with:
"abi: attempting to unmarshall an empty string while arguments are expected"
This comes from abi.go when it tries to Unpack the results in argument.go when contract.Call is called.
I read one speculation that this message is caused by incompatible genesis blocks?
Any help greatly appreciated.
abigen generated code works just fine on Go Quorum - nothing to do with genesis blocks. If your server IP that you are dailing and the contract IDs are not in sync, you'll get an empty result (with no error message).

How is it that the documented intent states in Lex are different from the actual available values?What is the difference between each of these states?

I am currently working on integrating aws Lex with lambda function written in TypeScript and I am facing a situation in which I need help .
Upon reading the aws documentation for LexV2 the following values are available for an intent state:
Failed
Fulfilled
FulfillmentInProgress
InProgress
ReadyForFulfillment
Waiting
However when I used the 'Waiting' value, The following error message showed up :
Invalid Lambda Response: Received invalid response from Lambda: Can not deserialize value of type Intent$IntentState from String "Waiting": value not one of declared Enum instance names: [ReadyForFulfillment, InProgress, Failed, Fulfilled]
Upon this I need help to:
Understand how is it possible to have values that are not recognized.
Understand the difference between each of these values (Note: not all of the accepted values are explained in the documentation)
After reaching out to aws support here is the answer:
LexV2 doesn't accept "FulfillmentInProgress" or "Waiting" as valid intent state.
Difference between each of the valid value:
ReadyForFulfillment - The bot is ready to fulfillment. Passing this state via lambda output will make the bot jump to fulfillment state
InProgress - The default state
Fulfilled - The bot will jump to closed state and will play back both the fulfillment success message and closing response
Failed - Mark the intent as failed; will result in bot playing the
fulfillment failure message

What are errorIndication, errorStatus and errorIndex providing in PySNMP's nextCmd()?

I would like to create proper error handling for the PySNMP function nextCmd() and am curious what the parameters errorIndication, errorStatus, and errorIndex are providing as I iterate through nextCmd().
I can not find anything within the documentation regarding these variables and would like to know more.
You can think of errorIndication as locally occurred errors. Misconfiguration or timeout will be reported via it.
The errorStatus and errorIndex pair can only come from the remote SNMP entity - that's the way how SNMP peers communicate their failures to us. Any non-zero errorStatus means an (enumerated) error. The accompanying errorIndex point to the first variable-binding in the request which might have caused the processing error being reported.

error: No usable messages given the current slot and sessionAttribute set

I made a chatbot in lex and for one particular intent, Lex is throwing the error,
An error has occurred: Invalid Bot Configuration: No usable messages
given the current slot and sessionAttribute set.
This error comes regardless of the input in case of that intent.
I am not using any lambda functions at this point for this intent.
Can someone guide me what this means? I am new to lex and I did not find references to what this error is about.
Recently I got the same error with the test of my bot after saving some changes. After a while, finally, I found out that it was because my confirmation message was using some slots not defined at that point.
Example:
Let's assume we have:
one required slot {name}
one optional slot {age}
and the confirmation message is "Your name is {name} and your age is {age}, is that right?"
If Lex reaches the point to ask for the user confirmation and {age} was never assigned whether in any utterance or a lambda function, then Lex will return this error.
You must ensure that all slots used in messages are defined.
I believe this error occurs because you have not configured Lex to have a response message set for that particular intent's CodeHook or Fulfillment.
If you are not using a Lambda Function for Fulfillment, be sure to select 'Return Parameters to Client' in the 'Fulfillment' section, then also supply a response message below that in 'Response' section.
Here's where to find that in the Lex Console:
when I had the error it was because my response was attempting to use a slot that I had deleted {reward}, check your response to make sure you are not attempting to add an inactive slot. Also, Make sure your intent is set to the Latest version.

Is it appropriate to use HTTP status codes for non-HTTP errors?

I know someone who is writing an API, and wants to use HTTP status codes to report the outcome of queries. e.g. if the user calls example.com/api/product_info?product_id=X, and the product doesn't exist, it would return HTTP status 400: Bad Request. I think that, since this is a valid call (i.e. the actual HTTP request is not malformed), it should return a 200 code response, and just have the body of the response something like {status: 'error'; message: 'No such product'}.
So my question is,
1) Is it appropriate to use HTTP status codes to convey non-HTTP program state, as in the example above?
2) Is there some standard, or at least widely used, specification describing when HTTP status codes are appropriate for use?
I was actually just talking about this the other day - http://blogs.mulesoft.org/api-best-practices-response-handling/
Your status code should reflect the response of the API, as 200 is "OK" and should be used for data that is successfully returned. However, 201 should be used for created items.
As mentioned already, in the event where the user tries a call but it fails (ie: users/?id=5) the server could return back a 400 to inform the user that it was a Bad Request, or a 404 if the resource doesn't exist.
It also depends on the action - if they are searching for a user and there are no responses, I wouldn't return an error, just a 200 with no results found. However, if they are trying to do a PUT or PATCH on a user that doesn't exist I would tell them with an error- as chances are there's a problem within their application somewhere.
In the link posted above you'll find more status codes, but one of the biggest advantages to using status codes is that it informs the client just though the header what actually happened with the server. This allows them to do a relatively quick (and low memory) check instead of having to deserialize the body and loop through an array looking for an errors key.
Essentially, you're giving them the tools to quickly and easily understand what is happening- something that I think every (sane) developer appreciates.
Hope this helps!
- Mike

Resources