Hi, +1 for the second option of handling it simply within our code level without going through the additional hop.
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. >> > Do you mean that you are going to have store all device notifications jobs in memory? Ie, it scales up with number of devices? 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. >> > Thanks, Sinthuja. >> 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/ >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sinthuja Rajendran* Technical Lead WSO2, Inc.:http://wso2.com Blog: http://sinthu-rajan.blogspot.com/ Mobile: +94774273955
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
