temporalio / temporalio/sdk-java
@SignalMethod threading configuration
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 433
- Forks
- 249
- Avg merge
- 5d 6h
- Merged PRs (30d)
- 26
Description
Is your feature request related to a problem? Please describe.
Each signal causes execution of a method annotated with @SignalMethod in its own thread. It means if the signal handling method blocks execution all other signals are still delivered through other threads.
In some scenarios the preferred semantic would be using a single thread to deliver all signals of the given type. This way workflow can flow control their processing. So while signal handling method is blocked all other signals are queued up waiting for thread to become available.
Describe the solution you'd like
Default signal handling to a single thread and provide an option through @SignalMethod parameter to multithreaded dispatch. Or do not provide multithreaded dispatch at all.
Describe alternatives you've considered
Keep it as it is.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. Start by locating the @SignalMethod implementation and its signal-dispatch path, then inspect how handler threads are selected. Done means the issue's chosen default and configuration option are implemented with coverage for queued single-threaded delivery and multithreaded dispatch if retained.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100