Thanks for the analysis. I suspect the nanoTime() call can be swapped out 
for a better alternative?



--Misagh



From: [email protected] [mailto:[email protected]] On Behalf Of Travis 
Schmidt
Sent: Friday, April 21, 2017 11:42 AM
To: [email protected]
Subject: [cas-dev] Problem with long id when using JSON Service Registry



I ran across this issue in 4.2.6, but it looks like it is still be an issue 
with 5.0.x and the 5.1 candidate releases.



The id field in AbstractRegisteredService is defined as this:



@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private long id = RegisteredService.INITIAL_IDENTIFIER_VALUE;


Defined as long to be compatible with database sequence generators when 
using JPA registry.  JSONServiceRegistryDao populates the value like this:



if (service.getId() == RegisteredService.INITIAL_IDENTIFIER_VALUE && service 
instanceof AbstractRegisteredService) {
    LOGGER.debug("Service id not set. Calculating id based on system 
time...");
    ((AbstractRegisteredService) service).setId(System.nanoTime());
}

This sets the id to a really long value most likely to be unique to each 
service.  A file name to store the registry is generated like this:



final String fileName = StringUtils.remove(service.getName() + '-' + 
service.getId() + '.' + FILE_EXTENSION, " ");

What we have observed recently on more than one occasion is that the id 
stored in the file and the id string used to save the file will be off by 
one digit.  Seems like precision is lost and the value is rounded up or down 
by one digit.



I think this is happening in the JSON serializer.  At least I did find 
mentions of this happening when doing a google search, but they seemed 
mostly to reference this happening in a browser not on the back-end.  I was 
not able to find any mention that Long.toString() could be loosing precision 
anywhere.



For the most part this does not cause an issue until the service is edited 
or attempted to be deleted.  Then the filename is recreated with the same 
expression as above.  In the case of editing, a new file is created and the 
old one never deleted, causing the duplicate id messages to appear in logs. 
The file can never be deleted because the same file name will never be 
created again.



Travis







-- 
You received this message because you are subscribed to the Google Groups 
"CAS Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to [email protected] 
<mailto:[email protected]> .
Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.

Reply via email to