I am setting up an existing app in iOS6 to work with simperium, all has been going well for a few weeks but today I started seeing these errors.
I deleted the App in Simperium and started with a fresh app but still get the error.
The test case is an upgrade for an existing user who already has data in coredata. so they create the simperium account and this is the first sync simperium does.
2012-11-14 10:46:31:931 Simperium POST returned error 409 for change {
ccid = da3d0c7bed984f88872f9e7d7527f0f9;
clientid = "ios-ca84b5cc41cc00962c1141a2854aeee0";
error = 409;
id = 54f58c57de65485f889aa4b30c39c54b;
r = (
50a3760437a401650500001b
);
}
I also see some of these errors but not so many :
2012-11-14 10:44:52:823 Simperium error: transform diff for a ghost member (ghost <SPGhost: 0x1d6324c0>, memberData (null)) that doesn't exist (showInDropDown): {
o = "+";
v = 0;
}
Also this :
Simperium timeout, server didn't respond to GET code 504 (ClipModel82),
The 504 is an expected timeout. The other errors are not expected. 409 is a duplicate change, which is ignored but shouldn't happen. The transform error could be happening if you're making changes via a non-iOS client to an attribute that doesn't exist in your Core Data model.
A couple things to try: use the "iosupdate" branch that is on GitHub as of this writing. It has the latest changes and fixes. Also try setVerboseLoggingEnabled:YES and get in touch with us by email, including log output as an attachment (help#simperium.com).
Related
Getting a strange error from QBFC. This code fails:
var qbRequest = sessionManager.CreateMsgSetRequest("US", 7, 0);
qbRequest.Attributes.OnError = ENRqOnError.roeStop;
var qbQuery = qbRequest.AppendCustomerQueryRq();
// Don't get all fields (would take forever) - just get these...
qbQuery.IncludeRetElementList.Add("ListID");
qbQuery.IncludeRetElementList.Add("Phone");
qbQuery.IncludeRetElementList.Add("AltPhone");
qbQuery.IncludeRetElementList.Add("Fax");
var qbResponses = sessionManager.DoRequests(qbRequest);// <<- EXCEPTION: INVALID TICKET PARAMETER !!!
However - if I just put a delay in there it works fine. e.g.
System.Threading.Thread.Sleep(1000);
var qbResponses = sessionManager.DoRequests(qbRequest);// <<- WORKS FINE!!
I found this out because anytime I would set a breakpoint in the code to debug the problem - the problem would go away. So then I learned that I could just put a 1 second Sleep in there and simulate the same behavior. (btw - half second delay doesn't help - still throws exception)
This has got me scratching my head. I initialize the sessionManager at the start of the app and reuse it throughout my code. And it works everywhere else in this app but here. I have looked at the raw XML (for both request and response) and don't see anything wrong in there. The response just has an error: "The data file is no longer open. Cannot continue." but nothing to indicate why. (and the data file is open, after this exception I can use it for any number of OTHER things)
I suspect it has something to do with WHEN this code is called. I have a listener that listens for messages from the XDMessaging add-in (used for inter-process communication). When the listener receives a message the event calls this code. But this code is called in the same app (and same thread) as tons of OTHER QBFC code I have that does very similar stuff without a problem. And if it was a threading issue I would think the error would happen regardless of if I Sleep() for a second or not.
Anybody have any ideas?
What version of QBSDK are you using and what version of QuickBooks? I tested using QBSDK 13 (though I specified version 7 when creating the message request), with version 14.0 Enterprise R5P. I experienced no problems or exceptions without having a delay. Perhaps there's something going on with your SessionManager since it appears that you've already opened the connection and began the session elsewhere?
Here's my code that had no problem:
QBSessionManager SessionMananger = new QBSessionManager();
SessionMananger.OpenConnection2("Sample", "Sample", ENConnectionType.ctLocalQBD);
SessionMananger.BeginSession("", ENOpenMode.omDontCare);
IMsgSetRequest MsgRequest = SessionMananger.CreateMsgSetRequest("US", 7, 0);
MsgRequest.Attributes.OnError = ENRqOnError.roeStop;
var qbQuery = MsgRequest.AppendCustomerQueryRq();
qbQuery.IncludeRetElementList.Add("ListID");
qbQuery.IncludeRetElementList.Add("Phone");
qbQuery.IncludeRetElementList.Add("AltPhone");
qbQuery.IncludeRetElementList.Add("Fax");
IMsgSetResponse MsgResponse = SessionMananger.DoRequests(MsgRequest);
for (int index = 0; index < MsgResponse.ResponseList.Count; index++)
{
IResponse response = MsgResponse.ResponseList.GetAt(index);
if (response.StatusCode != 0)
{
MessageBox.Show(response.StatusMessage);
}
}
Hello Simperium users,
what does this error mean / how to fix this ?
thanks
Frank
Error 412 means that the client sent a diff that caused no changes backend side. You can learn more about the Simperium protocol here:
https://github.com/Simperium/simperium-protocol/blob/master/SYNCING.md
Would it be possible to get the log that caused that error to show up?.
(+ May i ask you which Simperium version you're currently using? You can find that in the SPEnvironment class, constant SPLibraryVersion).
Thank you!
I'm trying to use Google's Play Games SDK for iOS. Upon signing my user in and then running one of their straight-forward methods:
[GPGSnapshotMetadata
openWithFileName:saveStoreName
conflictPolicy:GPGSnapshotConflictPolicyRemoteWins
completionHandler:^(GPGSnapshotMetadata *snapshot,
NSString *conflictId,
GPGSnapshotMetadata *conflictingSnapshotBase,
GPGSnapshotMetadata *conflictingSnapshotRemote,
NSError *error) {
NSLog(#"We got here. It must be an actual miracle.");
}];
instead of ever being sent to the completion handler, I get this error:
2014-07-13 22:01:33.700 MegaBits[6931:f007] WARNING: Returning empty data: id not found
2014-07-13 22:01:33.707 MegaBits[6931:f007] VERBOSE: Snapshot cache fully expired: refreshing all.
2014-07-13 22:01:33.892 MegaBits[6931:8d07] VERBOSE: Request had Apiary Status Code: 7
2014-07-13 22:01:33.894 MegaBits[6931:8d07] VERBOSE: Parsed error<http_code: 403, domain: usageLimits, reason: accessNotConfigured>
And those last 2 lines repeat a number of times.
I'm not sure what any of this means. It doesn't appear to be documented anyway, and so far as I can tell, Apiary is an API-generating startup. This error only comes from running this method. Commenting it out results in my code continuing to run smoothly. Apiary also isn't a service I'm using anywhere else.
We also haven't even approached 1% of our quota, so we're not being rate limited.
I am developing integration with Simperium, the integration is complete and has been running on test machines for sometime, I am starting to get this error on one of the devices and it keeps repeating constantly any ideas?
MeetingPad[891:1103] Simperium error (ActionLinks82), received an invalid change for (a18852011efe4964a6fdeb1853c790f3)
2013-02-07 10:07:05:277 MeetingPad[891:1103] Simperium client ios-7f43b434754d882923e966df5d885755 received change (ActionLinks82) ios-4176925448fa8ae0a2f1d0937627aa6b: {
ccids = (
3f3b4550b23147d49e194038feea09a6
);
clientid = "ios-4176925448fa8ae0a2f1d0937627aa6b";
cv = 5112df4b37a401031dcc5be1;
ev = 2;
id = 9ca0b7ad04314ab9888d75691be784b5;
o = "-";
}
If this occured on a user account what would be the guidance?
One thing to check is that you're using the latest version of the code. The repository was recently open sourced on GitHub. There used to be a bug related to nil values that could cause an invalid diff to appear in your change stream, but it should be fixed now.
Assuming you're using the latest code though, does the error repeat continuously for the same "id" value, or are there different values?
Looking at the Simperium code where this error occurs, it's possible it could be displayed if you've deleted an object locally and remotely at around the same time. In your app, might ActionLinks fit that pattern, i.e. are you creating and deleting a lot of them across multiple clients?
If that is indeed the cause, then the error is innocuous and we should patch the code. Let me know what you discover.
FATAL ERROR: CALL_AND_RETRY_2 Allocation Failed - process out of memory
I'm seeing this error and not quite sure where it's coming from. The project I'm working on has this basic workflow:
Receive XML post from another source
Parse the XML using xml2js
Extract the required information from the newly created JSON object and create a new object.
Send that object to connected clients (using socket.io)
Node Modules in use are:
xml2js
socket.io
choreographer
mysql
When I receive an XML packet the first thing I do is write it to a log.txt file in the event that something needs to be reviewed later. I first fs.readFile to get the current contents, then write the new contents + the old. The log.txt file was probably around 2400KB around last crash, but upon restarting the server it's working fine again so I don't believe this to be the issue.
I don't see a packet in the log right before the crash happened, so I'm not sure what's causing the crash... No new clients connected, no messages were being sent... nothing was being parsed.
Edit
Seeing as node is running constantly should I be using delete <object> after every object I'm using serves its purpose, such as var now = new Date() which I use to compare to things that happen in the past. Or, result object from step 3 after I've passed it to the callback?
Edit 2
I am keeping a master object in the event that a new client connects, they need to see past messages, objects are deleted though, they don't stay for the life of the server, just until their completed on client side. Currently, I'm doing something like this
function parsingFunction(callback) {
//Construct Object
callback(theConstructedObject);
}
parsingFunction(function (data) {
masterObject[someIdentifier] = data;
});
Edit 3
As another step for troubleshooting I dumped the process.memoryUsage().heapUsed right before the parser starts at the parser.on('end', function() {..}); and parsed several xml packets. The highest heap used was around 10-12 MB throughout the test, although during normal conditions the program rests at about 4-5 MB. I don't think this is particularly a deal breaker, but may help in finding the issue.
Perhaps you are accidentally closing on objects recursively. A crazy example:
function f() {
var shouldBeDeleted = function(x) { return x }
return function g() { return shouldBeDeleted(shouldBeDeleted) }
}
To find what is happening fire up node-inspector and set a break point just before the suspected out of memory error. Then click on "Closure" (below Scope Variables near the right border). Perhaps if you click around something will click and you realize what happens.