8.0 Java API to 7.6.4 server - update records issue
We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) However when the record gets updated… The log shows update T1 where c4 = 123456788 …… (Notice - the one second less than the create time) So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… However -- if you drop in the 7.6.4 client library -- it works fine. So … 8.0 client bug ??? or something else? -John -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
John, The only problem with that logic is that the server has always been in control of the create/modify date/time. To verify your scenario, you could quickly swap out the api that your java program is running for a 7.6.04 SP4, or even an 8.1 jar file for testing On Wed, Jun 12, 2013 at 9:50 AM, John Sundberg john.sundb...@kineticdata.com wrote: ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) However when the record gets updated… The log shows update T1 where c4 = 123456788 …… (Notice - the one second less than the create time) So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… However -- if you drop in the 7.6.4 client library -- it works fine. So … 8.0 client bug ??? or something else? -John -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
LJ -- agreed. And - since I posted -- the problem showed up with client 7.6.4 libraries too. (Just took awhile) But -- on close inspection -- the time stamp used on update is one second older than the timestamp on create. So -- definitely funky. (I would call it a server bug -- but I can't be sure) So -- 7.6.4 patch 2 server… reading the 3,4 update logs -- nothing jumps out as changing on the server that would fix this. May just update anyway -- maybe a change happened in the code - but did not make it into the release notes. -John On Wed, Jun 12, 2013 at 1:29 PM, Longwing, Lj llongw...@usgs.gov wrote: ** John, The only problem with that logic is that the server has always been in control of the create/modify date/time. To verify your scenario, you could quickly swap out the api that your java program is running for a 7.6.04 SP4, or even an 8.1 jar file for testing On Wed, Jun 12, 2013 at 9:50 AM, John Sundberg john.sundb...@kineticdata.com wrote: ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) However when the record gets updated… The log shows update T1 where c4 = 123456788 …… (Notice - the one second less than the create time) So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… However -- if you drop in the 7.6.4 client library -- it works fine. So … 8.0 client bug ??? or something else? -John -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
NO, they would NEVER put something into the code base that they don't document and put in the release notes, would they? Yes...I would certainly recommend getting to SP4...it is by all means the most stable of all of the 7.6 releases. On Wed, Jun 12, 2013 at 12:36 PM, John Sundberg john.sundb...@kineticdata.com wrote: ** LJ -- agreed. And - since I posted -- the problem showed up with client 7.6.4 libraries too. (Just took awhile) But -- on close inspection -- the time stamp used on update is one second older than the timestamp on create. So -- definitely funky. (I would call it a server bug -- but I can't be sure) So -- 7.6.4 patch 2 server… reading the 3,4 update logs -- nothing jumps out as changing on the server that would fix this. May just update anyway -- maybe a change happened in the code - but did not make it into the release notes. -John On Wed, Jun 12, 2013 at 1:29 PM, Longwing, Lj llongw...@usgs.gov wrote: ** John, The only problem with that logic is that the server has always been in control of the create/modify date/time. To verify your scenario, you could quickly swap out the api that your java program is running for a 7.6.04 SP4, or even an 8.1 jar file for testing On Wed, Jun 12, 2013 at 9:50 AM, John Sundberg john.sundb...@kineticdata.com wrote: ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) However when the record gets updated… The log shows update T1 where c4 = 123456788 …… (Notice - the one second less than the create time) So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… However -- if you drop in the 7.6.4 client library -- it works fine. So … 8.0 client bug ??? or something else? -John -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Sundberg Sent: Wednesday, June 12, 2013 8:51 AM To: arslist@ARSLIST.ORG Subject: 8.0 Java API to 7.6.4 server - update records issue ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server... The issue is -- a record is created at 2013-06-10T12:00:00 ... (call this 123456789) However when the record gets updated... The log shows update T1 where c4 = 123456788 .. (Notice - the one second less than the create time) So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it... However -- if you drop in the 7.6.4 client library -- it works fine. So ... 8.0 client bug ??? or something else? -John -- John Sundberg Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.commailto:john.sundb...@kineticdata.com www.kineticdata.comhttp://www.kineticdata.com/ I community.kineticdata.comhttp://community.kineticdata.com/ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
returned from the get API call? see above for issues if it is the client time. ** ** Scenario 3 – Are you worried about whether the entry has been changed by someone else since the time you retrieved it? If not, why aren't you setting the retrieved time to 0 to eliminate the test that is done on the modify as you don't need the test run, you are just modifying without checking if someone else has changed the record. ** ** ** ** We have seen absolutely no issue with any program that is using the Java API correctly in this area. We have hundreds of customers using 8.0 and 8.1 programs and mid-tiers against 7.6.04 (and 7.6.03 and 7.6 and 7.5 and …) servers and none have reported an issue in this area. And, as you have found, it isn't about the 8.1 API as the issue occurs when using 7.6.04 as well. ** ** Now, there is always a chance that no other customer has encountered an issue with any of their programs and there is something wrong in the code. It is software and you can never discount things. But, the logic around this area has been stable for many releases and there have been no reports of problems. ** ** Do you fall into one of the 3 scenarios I noted above? Should you be a scenario 3? ** ** But, regardless, it is modified-date that is involved so create-date is a distraction. And, one second off is no kind of an off by one error within the API/server as there is never any manipulation of the date, just what date and from where is used. There is no processing of the data value itself. ** ** ** ** I hope this helps explain the process that the system uses and points to some ideas for solution within your code. ** ** Doug Mueller ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *John Sundberg *Sent:* Wednesday, June 12, 2013 8:51 AM *To:* arslist@ARSLIST.ORG *Subject:* 8.0 Java API to 7.6.4 server - update records issue ** ** ** ** ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… ** ** The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) ** ** However ** ** when the record gets updated… ** ** The log shows ** ** update T1 where c4 = 123456788 …… ** ** (Notice - the one second less than the create time) ** ** So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… ** ** However -- if you drop in the 7.6.4 client library -- it works fine. ** ** ** ** So … 8.0 client bug ??? or something else? ** ** ** ** ** ** ** ** ** ** -John ** ** ** ** ** ** ** ** -- *John Sundberg* *Kinetic Data, Inc.* *Your Business. Your Process.* ** ** 651-556-0930 I* *john.sundb...@kineticdata.com www.kineticdata.com I* *community.kineticdata.com ** ** ** ** _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
. ** ** Scenario 2 – Is your code getting the entry that was created by someone else and then updating it? If so, what timestamp are you using for the retrieved time? Are you using the client time or a time returned from the get API call? see above for issues if it is the client time. ** ** Scenario 3 – Are you worried about whether the entry has been changed by someone else since the time you retrieved it? If not, why aren't you setting the retrieved time to 0 to eliminate the test that is done on the modify as you don't need the test run, you are just modifying without checking if someone else has changed the record. ** ** ** ** We have seen absolutely no issue with any program that is using the Java API correctly in this area. We have hundreds of customers using 8.0 and 8.1 programs and mid-tiers against 7.6.04 (and 7.6.03 and 7.6 and 7.5 and …) servers and none have reported an issue in this area. And, as you have found, it isn't about the 8.1 API as the issue occurs when using 7.6.04 as well. ** ** Now, there is always a chance that no other customer has encountered an issue with any of their programs and there is something wrong in the code. It is software and you can never discount things. But, the logic around this area has been stable for many releases and there have been no reports of problems. ** ** Do you fall into one of the 3 scenarios I noted above? Should you be a scenario 3? ** ** But, regardless, it is modified-date that is involved so create-date is a distraction. And, one second off is no kind of an off by one error within the API/server as there is never any manipulation of the date, just what date and from where is used. There is no processing of the data value itself. ** ** ** ** I hope this helps explain the process that the system uses and points to some ideas for solution within your code. ** ** Doug Mueller ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *John Sundberg *Sent:* Wednesday, June 12, 2013 8:51 AM *To:* arslist@ARSLIST.ORG *Subject:* 8.0 Java API to 7.6.4 server - update records issue ** ** ** ** ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… ** ** The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) ** ** However ** ** when the record gets updated… ** ** The log shows ** ** update T1 where c4 = 123456788 …… ** ** (Notice - the one second less than the create time) ** ** So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… ** ** However -- if you drop in the 7.6.4 client library -- it works fine. ** ** ** ** So … 8.0 client bug ??? or something else? ** ** ** ** ** ** ** ** ** ** -John ** ** ** ** ** ** ** ** -- *John Sundberg* *Kinetic Data, Inc.* *Your Business. Your Process.* ** ** 651-556-0930 I* *john.sundb...@kineticdata.com www.kineticdata.com I* *community.kineticdata.com ** ** ** ** _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
, the server cannot be giving you a server timestamp, are you using a client timestamp of when you created it and if the server clock is a second or two different (ahead) or the entry is created over the boundary of a second since you saved the timestamp…. You can see the problem you are having. ** ** Scenario 2 – Is your code getting the entry that was created by someone else and then updating it? If so, what timestamp are you using for the retrieved time? Are you using the client time or a time returned from the get API call? see above for issues if it is the client time. ** ** Scenario 3 – Are you worried about whether the entry has been changed by someone else since the time you retrieved it? If not, why aren't you setting the retrieved time to 0 to eliminate the test that is done on the modify as you don't need the test run, you are just modifying without checking if someone else has changed the record. ** ** ** ** We have seen absolutely no issue with any program that is using the Java API correctly in this area. We have hundreds of customers using 8.0 and 8.1 programs and mid-tiers against 7.6.04 (and 7.6.03 and 7.6 and 7.5 and …) servers and none have reported an issue in this area. And, as you have found, it isn't about the 8.1 API as the issue occurs when using 7.6.04 as well. ** ** Now, there is always a chance that no other customer has encountered an issue with any of their programs and there is something wrong in the code. It is software and you can never discount things. But, the logic around this area has been stable for many releases and there have been no reports of problems. ** ** Do you fall into one of the 3 scenarios I noted above? Should you be a scenario 3? ** ** But, regardless, it is modified-date that is involved so create-date is a distraction. And, one second off is no kind of an off by one error within the API/server as there is never any manipulation of the date, just what date and from where is used. There is no processing of the data value itself. ** ** ** ** I hope this helps explain the process that the system uses and points to some ideas for solution within your code. ** ** Doug Mueller ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *John Sundberg *Sent:* Wednesday, June 12, 2013 8:51 AM *To:* arslist@ARSLIST.ORG *Subject:* 8.0 Java API to 7.6.4 server - update records issue ** ** ** ** ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… ** ** The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) ** ** However ** ** when the record gets updated… ** ** The log shows ** ** update T1 where c4 = 123456788 …… ** ** (Notice - the one second less than the create time) ** ** So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… ** ** However -- if you drop in the 7.6.4 client library -- it works fine. ** ** ** ** So … 8.0 client bug ??? or something else? ** ** ** ** ** ** ** ** ** ** -John ** ** ** ** ** ** ** ** -- *John Sundberg* *Kinetic Data, Inc.* *Your Business. Your Process.* ** ** 651-556-0930 I* *john.sundb...@kineticdata.com www.kineticdata.com I* *community.kineticdata.com ** ** ** ** _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.0 Java API to 7.6.4 server - update records issue
this time value is an explicit parameter to the call. I am not sure how it is set in the Java API. ** ** ** ** Scenario 1 – Is your code creating and then modifying the entry? Where do you get the timestamp you are using to pass to the modify call for when the entry was retrieved? Since you are not doing a get of the entry, the server cannot be giving you a server timestamp, are you using a client timestamp of when you created it and if the server clock is a second or two different (ahead) or the entry is created over the boundary of a second since you saved the timestamp…. You can see the problem you are having. ** ** Scenario 2 – Is your code getting the entry that was created by someone else and then updating it? If so, what timestamp are you using for the retrieved time? Are you using the client time or a time returned from the get API call? see above for issues if it is the client time. ** ** Scenario 3 – Are you worried about whether the entry has been changed by someone else since the time you retrieved it? If not, why aren't you setting the retrieved time to 0 to eliminate the test that is done on the modify as you don't need the test run, you are just modifying without checking if someone else has changed the record. ** ** ** ** We have seen absolutely no issue with any program that is using the Java API correctly in this area. We have hundreds of customers using 8.0 and 8.1 programs and mid-tiers against 7.6.04 (and 7.6.03 and 7.6 and 7.5 and …) servers and none have reported an issue in this area. And, as you have found, it isn't about the 8.1 API as the issue occurs when using 7.6.04 as well. ** ** Now, there is always a chance that no other customer has encountered an issue with any of their programs and there is something wrong in the code. It is software and you can never discount things. But, the logic around this area has been stable for many releases and there have been no reports of problems. ** ** Do you fall into one of the 3 scenarios I noted above? Should you be a scenario 3? ** ** But, regardless, it is modified-date that is involved so create-date is a distraction. And, one second off is no kind of an off by one error within the API/server as there is never any manipulation of the date, just what date and from where is used. There is no processing of the data value itself. ** ** ** ** I hope this helps explain the process that the system uses and points to some ideas for solution within your code. ** ** Doug Mueller ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *John Sundberg *Sent:* Wednesday, June 12, 2013 8:51 AM *To:* arslist@ARSLIST.ORG *Subject:* 8.0 Java API to 7.6.4 server - update records issue ** ** ** ** ** We have recently seen a sporadic issue with the 8.0 Java API against a 7.6.4 server… ** ** The issue is -- a record is created at 2013-06-10T12:00:00 … (call this 123456789) ** ** However ** ** when the record gets updated… ** ** The log shows ** ** update T1 where c4 = 123456788 …… ** ** (Notice - the one second less than the create time) ** ** So I think what is happening is that the client library is somehow losing a second (off by one error???) on the update. So - the update fails with This record has been updated since you last touched it… ** ** However -- if you drop in the 7.6.4 client library -- it works fine.*** * ** ** ** ** So … 8.0 client bug ??? or something else? ** ** ** ** ** ** ** ** ** ** -John ** ** ** ** ** ** ** ** -- *John Sundberg* *Kinetic Data, Inc.* *Your Business. Your Process.* ** ** 651-556-0930 I* *john.sundb...@kineticdata.com www.kineticdata.com I* *community.kineticdata.com ** ** ** ** _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers
