Perte de données GluonClient lors de l'enregistrement de la liste en local

Question

J'essaie de conserver les données localement en utilisant le GluonClient. Il travaille sporadiquement pour quelques éléments mais génère des erreurs pour la plupart.

J'initialize par:

GluonClient localClient = GluonClientBuilder.create() 
    .operationMode(OperationMode.LOCAL_ONLY) 
    .build(); 

J'utilise un RestClient pour récupérer des données à partir d'une API REST. Une fois la liste initialise je tente de sauvegarder les données localement (tentative en utilisant GluonClient pour cette lecture sans succès):

RestClient apiClient = RestClient.create().method("GET") 
    .host("http://localhost:8080/api") 
    .path("/path/to/data") 
    .queryParam("token","mytoken"); 
JobsIterableInputConverter<Job> converter = new JobsIterableInputConverter<>(Job.class); 
GluonObservableList<Job.class> jobs = (DataProvider.retrieveList(apiClient.createListDataReader(converter))); 
jobs.initializedProperty((obv,ov,nv)->{ 
    saveJobList(jobs); 
}); 


private void saveJobListLocally(GluonObservableList<Job> list){ 
    GluonObservableList<Job> eqs = DataProvider.retrieveList(gluonClient.createListDataReader("jobs", Job.class)); 
    eqs.initializedProperty().addListener((obv, ov, nv) -> { 
     if (nv && eqs.isEmpty()) { 
      eqs.addAll(list); 
     } 
    }); 
} 

Cela fonctionne pour certaines des données de temps en temps, environ 4 (pas toujours 4) objets d'emplois de 168 sont sauvés et le reste génèrent l'exception:

javax.json.stream.JsonParsingException: Invalid token=EOF at (line no=1, column no=0, offset=-1). Expected tokens are: [CURLYOPEN, SQUAREOPEN] 

Pour récupérer les données locales, je l'appelle:

jobs = DataProvider.retrieveList(gluonClient.createListDataReader("jobs", Job.class)); 

et cela fonctionne bien.

-Je peux accéder et utiliser les ~ 4 objets enregistrés, mais le reste est perdu.

-Les ~ 4 objets qui sont sauvegardés ne sont pas les mêmes d'un test à l'autre (partie la plus déroutante).

-Les données de chaque objet de travail ont été rendues identiques pour tester si les données n'étaient pas valides ou s'il y avait des caractères non valides mais ont vu le même problème. Avoir déjà analysé et utilisé des données dans d'autres applications en utilisant org.json.

- Occasionnellement, des fichiers sont générés pour chaque objet 'perdu' avec l'UID comme nom de fichier en plus du fichier de jobs. - Je n'ai vu aucune exception levée mais la plupart des données manquaient encore.

-La classe d'objet utilise IntegerProperty et StringProperty pour les types de données. Getters annoté avec @XMLElement

Le comportement que je vois du GluonClient est incohérent.

J'ai essayé d'utiliser FileClient mais cela ne fonctionne pas avec une liste (devrais-je être sur cette piste?). Comment utiliser le GluonClient pour enregistrer et gérer le contenu local sous forme de liste?

En utilisant javafxportsVersion= '8.60.7'

public class JobsIterableInputConverter<E> extends InputStreamIterableInputConverter<E> implements Iterator<E> { 

    private JsonArray jsonArray = null; 
    private int index; 
    private final JsonConverter<E> converter; 

    public JobsIterableInputConverter(Class<E> targetClass) 
    { 
     converter = new JsonConverter<>(targetClass); 
    } 

    @Override 
    public boolean hasNext() 
    { 
     if (jsonArray == null) { 
      return false; 
     } 
     return index < jsonArray.size(); 
    } 

    @Override 
    public E next() 
    { 
     JsonObject jsonObject = jsonArray.getJsonObject(index++); 
     return converter.readFromJson(jsonObject); 
    } 

    @Override 
    public Iterator<E> iterator() 
    { 
     index = 0; 

     try (JsonReader reader = Json.createReader(getInputStream())) { 
      JsonObject jsonObject = reader.readObject(); 
      jsonArray = jsonObject.getJsonArray("jobs"); 
     } 

     return this; 
    } 
} 

API Retour Format:

{"jobs":[ 
    {"id":0}, 
    {"id":1} 
]} 

Answer 1

Il y avait en effet un bug qui se manifeste lors de l'enregistrement de nombreux éléments dans une liste de stockage local. La raison de la corruption de JSON est qu'il y avait un accès simultané possible au fichier local dans lequel les objets sont stockés.Le bug a déjà été corrigé avec la requête de tirage suivante: https://bitbucket.org/gluon-oss/gluon-connect/pull-requests/1/make-sure-there-is-no-simultaneous-access/diff

Une nouvelle version est prévue quelque part cette semaine.