Hi Chathura, We can not read from db , since in a clustered environment when multiple nodes try read from same operation table will cause duplication of push message sending. Anyway these bulk device request will come to given node at a time. So device can store them in queue for temporary for sending push messages as batches. If node restart we can have retry task ( Only in manager node) to read from database.
Thanks, Waruna On Wed, Mar 22, 2017 at 3:58 PM, Chathura Ekanayake <[email protected]> wrote: > I think option 2 is better. Using a message store will also eventually > access a persistent storage (probably with multiple io calls), so the > additional db call in option 2 is not significant. In addition, option 1 > adds an additional hop to the message flow. > > Why do we need a concurrent queue for option 2 (as we anyway store all > operations in db)? Is it as a cache? > > - Chathura > > On Wed, Mar 22, 2017 at 11:52 AM, Waruna Jayaweera <[email protected]> > wrote: > >> Hi, >> >> In Device + Server Communication Push notifications used to notify >> devices to retrieve the device operations. This also use in policy >> monitoring where we send push notification to all devices during monitoring >> task. There are different push notification strategies as for APNS, for >> android - GCM/FCM and for Windows - WNS also MQTT based push notifications. >> >> *Problem* >> In current implementation when you set device operation to multiple >> devices, or during policy monitoring >> all push notifications are send all devices at once. This will cause >> sudden request burst when all devices try access the server for device >> operations. We also needs to think about of reliability of push >> notifications if those got failed. To solve this issue we have multiple >> solutions. >> >> *Solutions* >> >> *1) Use Message store and Message Processors* >> >> We can send each push notification message to inbuilt synapse message >> store via proxy. Then we can have sampling message processor to send those >> push notifications to given notification provider. In sampling message >> processor we can define no of message per given time and time interval per >> batch of messages. Push notification logic will be inside sequence with >> custom mediator. >> >> Pros; >> Reliability can be achieved using jms message store. >> minimum code >> >> Cons; >> IOT server have to depend on message processors. >> >> >> *2) Java Queue with Scheduler Task* >> >> We can have java concurrent queue to store device notifications as batch >> jobs. Scheduler task will be there to read jobs and process them and send >> notifications. Batch job object will content set of devices given batch >> size and scheduler task will be run based on delay interval. >> >> Pros; >> Do not need to rely on other feature >> >> Cons; >> We need to maintain push status in database so there will be additional >> database call in order to make reliability of notification sending. Later >> we can have retry logic to failed notifications based on db status. >> >> If device list is below the no of devices per batch, those commands will >> send immediately. >> IMO option 2 is better since we do not rely on any other implementation. >> Appreciate any suggestions. >> >> Thanks, >> Waruna >> >> -- >> Regards, >> >> Waruna Lakshitha Jayaweera >> Senior Software Engineer >> WSO2 Inc; http://wso2.com >> phone: +94713255198 <+94%2071%20325%205198> >> http://waruapz.blogspot.com/ >> >> > -- Regards, Waruna Lakshitha Jayaweera Senior Software Engineer WSO2 Inc; http://wso2.com phone: +94713255198 http://waruapz.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
