Scénario d'utilisation de la file d'attente de blocage

Je travaille sur une conception dans laquelle je traite toutes les exceptions capturées dans des blocs catch pour les envoyer à un serveur via un appel de service Web.Scénario d'utilisation de la file d'attente de blocage

L'idée n'est pas de bloquer l'application principale du tout en faisant ce travail. Je pensais que le motif de la file d'attente bloquante est approprié pour cela. J'ai donc créé une file d'attente de blocage en utilisant l'implémentation de tableau avec la taille 10. Au début de l'application principale, j'initialise un thread consommateur pour cette file d'attente.

Cependant, le côté producteur est peu confus pour moi. si je comprends bien, la file d'attente est pleine et si l'application principale a rencontré une exception, alors faire un producer.put (objet) serait bloqué jusqu'à ce que la file d'attente ait de l'espace et donc l'application principale se bloquera aussi. est-ce que c'est une bonne compréhension?

Source

2016-02-04 Vik

Oui, le thread du producteur sera bloqué jusqu'à ce que le thread consommateur en prenne un dans la file d'attente. –

hmm alors ce n'est pas bon car le bloc catch sera accroché et cela signifie que l'application principale sera aussi accrochée. – Vik

Oui, vous avez raison. Voici un très utile table of BlockingQueue methods Habituellement, il est bon d'avoir une file d'attente limitée, mais la limite ne devrait pas être très faible.

Source

2016-02-04 18:53:45 dezhik

c'est pour une application mobile, donc ne voulez pas le laisser causer des problèmes de mémoire. par conséquent gardé le conservateur 10. Mais il bloquera alors devrais-je faire l'opération de la file d'attente en créant des discussions anonymes? – Vik

100 ou même 1000 serait beaucoup trop, car dans le cas d'une application mobile, il pourrait y avoir aucune connexion réseau, et dans ce cas, vous ne pouvez pas envoyer d'exceptions à un serveur. Je vous suggère d'utiliser 'offer (e)', car sinon, en cas d'erreurs réseau ou de redémarrage du serveur, vos threads en production pourraient être bloqués. Vous pouvez également avoir un compteur pour les cas où 'offer (e)' renvoie 'false' et le vider de temps en temps sur le serveur s'il est supérieur à 0 – dezhik

bien pour le consommateur l'idée de faire un appel et si elle échoue pour les problèmes de réseau, puis le pousser à sqlite locale db. afin qu'ils puissent être retentés plus tard de DB. – Vik

Je pense que vous devriez écrire votre exception sur le stockage de téléphone (SharedPreferences si Android) au lieu de garder dans la mémoire principale. Tout d'abord, il ne bloquera pas votre application principale.

Et au rappel connecté au réseau, démarrez un thread qui lira à partir des préférences partagées et l'enverra au serveur.

Source

2016-02-04 19:03:21

bien qu'une base de données sqlLite locale est en effet un composant requis pour gérer la situation lorsque le périphérique n'est pas connecté au réseau. Cependant, l'écriture est coûteuse et il s'agit d'un DB unique, donc dans les situations où trop d'exceptions sont générées, le système global sera dépassé. – Vik

Synchronisez vos méthodes DAO et utilisez AsyncTasks pour écrire des exceptions dans la base de données. Ce qui signifie que seulement sur AsyncTask sera autorisé à écrire une exception à DB, tandis que l'application principale ne sera pas suspendue parce que nous utilisons AsyncTasks. –

Scénario d'utilisation de la file d'attente de blocage

Répondre

Questions connexes