Сценарий использования блокировки очереди

Я работаю над дизайном, где я обрабатываю все исключения, пойманные в блоки catch, для отправки на сервер через вызов webservice.Сценарий использования блокировки очереди

Идея состоит не в том, чтобы вообще блокировать основное приложение, выполняя эту работу. Я чувствовал, что шаблон блокировки очереди подходит для него. Итак, я создал блокирующую очередь с использованием реализации массива с размером 10. В начале основного приложения я инициализирую потребительский поток для этой очереди.

Однако сторона производителя немного запутывает меня. по моему пониманию, если очередь заполнена, и если основное приложение попадает в исключение, тогда выполнение объекта production.put (object) будет заблокировано до тех пор, пока очередь не будет иметь место, и, следовательно, основное приложение также заблокирует. это правильное понимание?

источник

2016-02-04 Vik

Да, поток производителя будет заблокирован до тех пор, пока потребительский поток не займет один из очереди. –

Хмм, тогда это не хорошо, поскольку блок catch будет висел, и это означает, что основное приложение также будет висели. – Vik

Да, вы правы. Здесь очень полезно table of BlockingQueue methods Обычно полезно иметь ограниченную очередь, но предел не должен быть очень низким.

источник

2016-02-04 18:53:45 dezhik

это для мобильного приложения, поэтому не хотите, чтобы это вызывало проблемы с памятью. следовательно, сохранил его консервативно 10. Но он будет блокировать, если я должен выполнить операцию очереди, создав анонимные потоки? – Vik

100 или даже 1000 будет слишком много, потому что в случае мобильного приложения не может быть сетевого подключения, и в этом случае вы не можете отправлять исключения на сервер. Я предлагаю вам использовать 'offer (e)', потому что в противном случае в случае сетевых ошибок или перезапуска сервера ваши потоки могут быть заблокированы. Кроме того, у вас может быть счетчик для случаев, когда 'offer (e)' возвращает 'false' и время от времени очищает его до сервера, если она больше 0 – dezhik

хорошо для потребителя идея сделать звонок, и если он не сработает из-за необходимости к сетевым проблемам, затем нажмите на локальный SQL-адрес. так что их можно было бы повторить позже из БД. – Vik

Я думаю, вы должны написать свое исключение для хранения телефона (SharedPreferences, если Android), вместо того, чтобы хранить в основной памяти. Во-первых, он не будет блокировать ваше основное приложение.

И при подключении к сети, запустите поток, который будет считываться из общих настроек и отправлять его на сервер.

источник

2016-02-04 19:03:21

а локальная база данных sqlLite действительно является необходимым компонентом для обработки ситуации, когда устройство не подключено к сети. однако запись на него является дорогостоящей, и это единственный поток db, поэтому в ситуациях, когда генерируется слишком много исключений, общая система будет перегружена. – Vik

Синхронизируйте свои методы DAO и используйте AsyncTasks для записи исключений в БД. Это означает, что только на AsyncTask будет разрешено писать исключение в БД, в то время как основное приложение не будет повешено, потому что мы используем AsyncTasks. –

Сценарий использования блокировки очереди

ответ

Смежные вопросы