50 queues is this a per app in apphq or per installed app on device?

Question

Hi,

 

We are using the message queue as a comunication layer to send commands to the installed app on a device (1 user per installed app). I have not seen this limitation before in the documentation so I was wondering if this is a per app limitation as

1. app in the apphq console; or
2. installed app on a device.

At this moment we are way over these 50 queues in situation 1. but wille never reach the number of queues in situation 2. Can you please clear this for me?

 

Thanks!

Answer 1

Restriction is on per app basis and not on per install/user. If you want to have more queue in the app, you have to move to our paid plan.

Let me know if it helps.

Comments

Thanks for your answer, its clears out a bit. But when we have a payed plan (small in our case) what are the restrictions or is there no restriction on payed plans. I ask this because I could not find any documentation on the limitations.

---

In small paid plan you can maximum have 100 queues and highest you can move upto 200 queues only. I would recommend to use AppWarp (http://appwarp.shephertz.com) in case if you have chat based use case in your app as message queue is not recommended for it.

---

We do not use the queue service for chat messages, and using appwarp as alternative is not an option because it does not support a user to be playing multiple turn based games at the time and retrieving all the move information without entering the room (http://forum.shephertz.com/?qa=3405/turn-based-room-have-more-subscriptions-active-joined-users). Or I must have really misunderstood Suyash Mohan.

In our situation the queue service is used to send commands from one user (installed app) to another and act upon that. We were expecting to have the push option soon, but I feel we are forced to take another approach on this command communication between users (installed apps).

---

I think then in that case simple solution would be to use Storage service to store the message of one user to another user. You can apply a query to fetch message for user and after reading it just delete it. Have a look  here for complete tutorial on it http://api.shephertz.com/tutorial/Saving-App-Data/?index=storage-data

---

That was the precise option I was heading to, but this option does costs a lot of api calls. That is the reason we decided in our architecture to use the queue option instead an wait/hope for a soon push option in the queue.

We have hundreds of queues at this moment, do I have to worry on this very soon or is there time to change our app and upload it to Apple (takes at least 4 weeks to complete this change to get into production state).

---

I will request to change your option to Push/Storage based solution instead of queue in future release. This will just increase one API call/user case for deletion and pricing point of view this would be a cheaper option. For your current  production release you dont need to worry about it as it looks like a genuine case so we will probably not charge it from you nor will stop your app however request you to write a mail at support@shephertz.com mentioning that you need x number of  queue quota till given time line (Time until your updated release is up in the app store).

Let me know if it helps.