Forum Discussion

rajpi's avatar
rajpi
Adept
8 years ago

503 - Service unavailable back-end server is at capacity

Hi,

 

I am constantly getting "503 Service Unvailable Back-end server is at Capacity" for "SELECT subject, id FROM messages WHERE conversation.last_post_time > 2017-02-02T10:04:30-08:00 AND conversation.last_post_time < 2017-03-03T10:04:30-08:00 AND depth=0 ORDER BY conversation.last_post_time DESC"

Sometimes "Select * from Messages", "Select * from Boards" are working.

I am not firing queries too quick though --> Once call per 15 mins.

1. Are there any rate limits applied on the calls

2. How do I get messages based on the post_time --> This is not working when I used it with messages LiQL

3. How can I do paging (fetch multiple pages) with subsequent calls

 

Any advise ?

 

Thanks

Raj

  • cike's avatar
    cike
    8 years ago

    Hi rajpi,

     

    I don't think that there is a special rate limit on queries, but you should reduce the amount of your API calls to a minimal level. Maybe you could ask Lihtium Support for further investigation (log file analysis, etc.) to find the cause for your 503 response.

     

    Your post time filter should work as expected. I tested your query successfully. Is your time range set correctly and can you confirm that you have any posts in this range? Maybe you will some additional information in the developers documentation.

     

    If you want to handle more results (> 25) you can add the LIMIT and OFFSET keywords to your query. The LIMIT defines your results per query and the OFFSET tells the system at which result id the list should be started.

     

    For example, get the first 10 results:

    SELECT subject, id FROM messages WHERE conversation.last_post_time > 2017-02-02T10:04:30-08:00 AND conversation.last_post_time < 2017-03-03T10:04:30-08:00 AND depth=0 ORDER BY conversation.last_post_time DESC LIMIT 10 OFFSET 0

    For results 11-20 adjust the OFFSET value:

    SELECT subject, id FROM messages WHERE conversation.last_post_time > 2017-02-02T10:04:30-08:00 AND conversation.last_post_time < 2017-03-03T10:04:30-08:00 AND depth=0 ORDER BY conversation.last_post_time DESC LIMIT 10 OFFSET 10

    Hope, this helps you to go. :)

     

    Best regards,

    Christian

4 Replies

Sort By
  • cike's avatar
    cike
    Champion
    8 years ago

    Hi rajpi,

     

    I don't think that there is a special rate limit on queries, but you should reduce the amount of your API calls to a minimal level. Maybe you could ask Lihtium Support for further investigation (log file analysis, etc.) to find the cause for your 503 response.

     

    Your post time filter should work as expected. I tested your query successfully. Is your time range set correctly and can you confirm that you have any posts in this range? Maybe you will some additional information in the developers documentation.

     

    If you want to handle more results (> 25) you can add the LIMIT and OFFSET keywords to your query. The LIMIT defines your results per query and the OFFSET tells the system at which result id the list should be started.

     

    For example, get the first 10 results:

    SELECT subject, id FROM messages WHERE conversation.last_post_time > 2017-02-02T10:04:30-08:00 AND conversation.last_post_time < 2017-03-03T10:04:30-08:00 AND depth=0 ORDER BY conversation.last_post_time DESC LIMIT 10 OFFSET 0

    For results 11-20 adjust the OFFSET value:

    SELECT subject, id FROM messages WHERE conversation.last_post_time > 2017-02-02T10:04:30-08:00 AND conversation.last_post_time < 2017-03-03T10:04:30-08:00 AND depth=0 ORDER BY conversation.last_post_time DESC LIMIT 10 OFFSET 10

    Hope, this helps you to go. :)

     

    Best regards,

    Christian

  • ChiaraS's avatar
    ChiaraS
    Lithium Alumni (Retired)
    8 years ago

    I think there was an issue with the API proxy over the weekend which should be resolved now. Anyway, Support will have more details around it...

  • rajpi's avatar
    rajpi
    Adept
    8 years ago

    Thanks ChiaraS, There was a API Proxy issue over the weekend, this is working now.