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/ > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
