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).
Related
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.
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.
I am trying to subscribe to iCloud changes but I keep getting an internal sever error. Saving and fethcing data from iCloud works, but I can not fetch nor save subscribtions.
Anyone know what could be the problem?
I have found the problem. CloudKit is very poorly documented when it comes to errors. Looks like you receive an internal server error when trying to subscribe for record changes, using a record type which does not exist yet. Weird, hope it helps someone in the future!
I have also noticed that once you encounter an error subsequent calls to CloudKit seem to fail silently. Perhaps its normal iOS behaviour, and I need to reset the error code if it gets set. Maybe someone else can comment.
I had the subscriptions working correctly until I added the subscriptionID. I then started receiving the "Internal server error". I was using the function:
let subscription = CKQuerySubscription(recordType: kActionFigureSpecificsRecord,
predicate: predicate,
subscriptionID: subscriptionId,
options: [.firesOnRecordCreation, .firesOnRecordUpdate, .firesOnRecordDeletion])
subscriptionID
The unique name of the subscription. This string must be unique in the specified database and must not be nil.
After reading the documentation, I realized that the subscriptionID needs to be unique, although the documentation wasn't particularly clear regarding unique relative to what. I believe the unique criteria is with respect to other database ID.names, such as other recordID.recordName. I had my subscriptionID string the same value as a recordID.recordName for the table on on which the subscription acted for the relevant record. When I appended _Subscription to the subscriptionID string (i.e., name), the subscription registered fine.
I'm trying to use the Go pubsub library against the local emulated pubsub server. I'm finding that the "old style" (deprecated) functions (e.g. CreateSub and PullWait) work find, but the "new style" API (e.g. Iterators and SubscriptionHandles) does not work as expected.
I've written two different unit tests that both test the same sequence of actions, one using the "new style" API and one using the "old style" API.
The sequence is:
create a subscription
fail to pull any messages (since none available)
publish a message
pull that message, but don't ACK it
lastly pull it again which should take 10s since the message ACK timeout has to expire first
https://gist.github.com/ianrose14/db6ecd9ccb6c84c8b36bf49d93b11bfb
The test using the old-style API works just as I would expect:
=== RUN TestPubSubRereadLegacyForDemo
--- PASS: TestPubSubRereadLegacyForDemo (10.32s)
pubsubintg_test.go:217: PullWait returned in 21.64236ms (expected 0)
pubsubintg_test.go:228: PullWait returned in 10.048119558s (expected 10s)
PASS
Whereas the test using the new-style API works unreliably. Sometimes things work as expected:
=== RUN TestPubSubRereadForDemo
--- PASS: TestPubSubRereadForDemo (11.38s)
pubsubintg_test.go:149: iter.Next() returned in 17.686701ms (expected 0)
pubsubintg_test.go:171: iter.Next() returned in 10.059492646s (expected 10s)
PASS
But sometimes I find that iter.Stop() doesn't return promptly as it should (and note how the second iter.Next too way longer than it should):
=== RUN TestPubSubRereadForDemo
--- FAIL: TestPubSubRereadForDemo (23.87s)
pubsubintg_test.go:149: iter.Next() returned in 7.3284ms (expected 0)
pubsubintg_test.go:171: iter.Next() returned in 20.074994835s (expected 10s)
pubsubintg_test.go:183: iter.Stop() took too long (2.475055901s)
FAIL
And other times I find that the first Pull after publishing the message takes too long (it should be near instant):
=== RUN TestPubSubRereadForDemo
--- FAIL: TestPubSubRereadForDemo (6.32s)
pubsubintg_test.go:147: failed to pull message from iterator: context deadline exceeded
FAIL
Any ideas? Are there any working examples using the new-style API? Unfortunately, the Go starter project here uses the old, deprecated API.
(Note: It looks like the line numbers in your example output don't match the code that you've linked.)
But sometimes I find that iter.Stop() doesn't return promptly as it should
A few changes have landed recently which fix the excessive delay when calling iter.Stop. It should now return promptly if all messages have been acked. Try syncing and testing it out again.
(and note how the second iter.Next too way longer than it should):
In you code that uses the new API, you first do a pull from an empty subscription, using a context with a 1s deadline. Let's call this "Pull request A". Although the underlying http request is cancelled, it seems that the connection is not being closed in any way that the server respects. So, as far as the server is concerned, "A" is still pending. Immediately after publishing, you make a new pull request, let's call that "B". After a message is returned via pull request B, you leave the message unacked, and make another pull request, "C".
Now, when you publish the message, the server will deliver it to either "A" or "B". If it delivers it to "A" first, you will see the first pull exceeding the 5s context deadline. If it is published to "B" first, you will see the first pull returning quickly, as expected. After the message is published to "B", and left unacked, the server will redeliver it to "A", or "C". If it picks "A" first, then you will end up with the second pull taking longer than expected. If it picks "C", then you will see both first and second pulls taking as long as you expect.
If you don't do that initial pull from the empty subscription, you should see your test behave as you expect.
Note: You don't see any of this when you use the old API because you're not doing the extra "pull from empty subscription" request with the old API (presumably because it doesn't properly support a cancellable context).
Aside: if you want to leave a message unacked, you should call Message.Done(false).
I want to send notifications to apple devices in batches (1.000 device tokens in batch for example). Ant it seems that I can't know for sure that message was delivered to APNs.
Here is the code sample:
ssl_connection(bundle_id) do |ssl, socket|
device_tokens.each do |device_token|
ssl.write(apn_message_for device_token)
# I can check if there is an error response from APNs
response_has_an_error = IO.select([socket],nil,nil,0) != nil
# ...
end
end
The main problem is if network is down after the ssl_connection is established
ssl.write(...)
will never raise an error. Is there any way to ckeck that connection still works?
The second problem is in delay between ssl.write and ready error answer from APNs. I can pass timeout parameter to IO.select after last messege was sent. Maybe It's OK to wait for a few seconds for 1.000 batch, but wat if I have to send 1.000 messages for differend bundle_ids?
At https://zeropush.com, we use a gem named grocer to handle our communication with Apple and we had a similar problem. The solution we found was to use the socket's read_non_block method before each write to check for incoming data on the socket which would indicate an error.
It makes the logic a bit funny because read_non_block throws IO::WaitReadable if there is no data to read. So we call read_non_block and catch IO::WaitReadable before continuing as normal. In our case, catching the exception is the happy case. You may be able to use a similar approach rather than using IO.select(...).
One issue to be aware of is that Apple may not respond immediately and any notifications sent between a failing notification and reading from the socket will be lost.
You can see the code we are using in production at https://github.com/SymmetricInfinity/grocer/blob/master/lib/grocer/connection.rb#L30.