Hi Waruna, On Wed, Mar 22, 2017 at 10:41 PM, Waruna Jayaweera <[email protected]> wrote:
> 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. > Can't we make use of dynamic partitioning for this case? i.e, we can dynamically partition the push requests based on number of nodes available in the cluster, and particular node will be serving the requests allocated for that node only. Anyway these bulk device request will come to given node at a time. So > device can store them in queue > You mean the node can store them in queue? Actually what sort of details you are going to hold in-memory? Is it basically going to have some sort of map where the device id is key, and the list of messges that needs to be pushed into the system as a list? In that case, scaling will be a problem? And what if that node goes down, how can we reload the state? I may be missing some details, but can you please explain full flow in bit more detail? Thanks, Sinthuja. 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 <071%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
