Parallel Tool Execution

[rafaelrddc]

Description
This MR adds parallel execution capability to DefaultToolCallingManager to process multiple AI tool calls concurrently instead of sequentially, significantly improving performance for applications requiring multiple independent tool interactions.

Resolves #4254

[sunyuhan1998]

I think, no matter what, we shouldn't hardcode thread pool configurations as "magic values" here, even if it's just a default thread pool. Perhaps we should introduce corresponding configuration options and a dedicated configuration class to manage these parameters.

[sunyuhan1998]

By the way, the spelling of the thread name also appears to be incorrect: "toll" should be "tool".

[rafaelrddc]

I can add it to the ToolCallingProperties class, which will allow us to customize the default values using properties. What do you think?

Exemple

@ConfigurationProperties(ToolCallingProperties.CONFIG_PREFIX)
public class ToolCallingProperties {

	public static final String CONFIG_PREFIX = "spring.ai.tools";

	private final Observations observations = new Observations();

	private final TaskExecutorProperties taskExecutor = new TaskExecutorProperties();
    
        public static class TaskExecutorProperties {
		/**
		 * Whether to enable custom task executor configuration for tool calls.
		 */
		private boolean enabled = false;

		/**
		 * Core number of threads in the pool.
		 */
		private int corePoolSize = Runtime.getRuntime().availableProcessors();

		/**
		 * Maximum number of threads in the pool.
		 */
		private int maxPoolSize = Runtime.getRuntime().availableProcessors() * 2;

		/**
		 * Capacity of the queue for holding tasks before they are executed.
		 */
		private int queueCapacity = 100;

		/**
		 * Prefix for thread names in the pool.
		 */
		private String threadNamePrefix = "tool-call-exec-";
	}
}

[sunyuhan1998]

Initializing the static thread pool by calling buildDefaultTaskExecutor() here causes the method to be executed regardless of whether the user provides a thread pool in the constructor, which seems inappropriate.

[rafaelrddc]

I just deployed a change tweaking this behavior. The system will now create a default instance only when no custom configuration is supplied.

[sunyuhan1998]

Is this intended to wait for all tools to finish execution in startup order? I'm not sure if this approach makes sense—would using CompletableFuture.allOf() be more appropriate?

[rafaelrddc]

I changed it to use allOf, but we still need to use join to get the responses. However, it will return immediately.