Skip to content

Feature Requests

← Customer Feedback for ServiceStack

Feature, docs and use-case samples requests for ServiceStack. If you can, focus on the end-user benefit / use-case, rather than the technical details so we can focus on the end-goal and free us to work on how best to achieve it. Features can also include supporting content, e.g. a starter project on how to use ServiceStack with another product (e.g. SS + SharePoint).

I suggest you ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

162 results found

  1. Web App support for accessing remote ServiceStack services

    Templates has a sendToGateway option. In a Web App it would be good if settings could be provided for the baseUrl for the ServiceStack service which should receive the request.

    0 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  2. Use a ThreadPool for RedisMqServer Services instead of hardcoding nbr of threads

    For increasing the throughput for a specific Request service in RedisMqServer, you need to manually hardcode the number of threads that the request/service has:

    https://docs.servicestack.net/redis-mq#easily-parallelize-and-multiply-your-services-throughput

    Like so:
    mqService.RegisterHandler<PostStatusTwitter>(ExecuteMessage, noOfThreads:2);

    I would like to suggest the option to use a ThreadPool instead.

    That would give the option to state the total number of concurrent/parallell processing, but there is no need to lock it down to specific requests. This is more versatile and less resource-wasting; if a certain Service isnt used right now, the threads can be used to process other Services instead.

    Maybe something like:

    mqService.UseThreadPool = true;
    mqService.MaxNbrOfThreads = 50;

    …

    0 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    AdminDemis J Bellot (Developer, ServiceStack) responded

    Usage of a dedicated thread per Message Type is per design so throughput can be controlled per Type, sequential processing can be enforced and processing is isolated from long tail of other lower priority MQ Messages delaying processing of higher priority ones.

    You can reduce number of sleeping threads by having fewer MQ Types, i.e. combining multiple MQ Tasks into a single union type whose Service implementation can delegate into invoking their different individual services.

    Mixing Threadpool MQ Server strategies will not happen with the existing implementation, it requires a completely new implementation with different behavior & design goals.

    I’ll leave this feature request open in-case anyone decides to implement a different MQ Server strategy and can post a link to their implementation here.

1 2 … 5 6 7 9 Next →
  • Don't see your idea?

Feature Requests

Categories

Feedback and Knowledge Base

(thinking…)