Um dia, a página da web no servidor não pôde ser aberta e o seguinte erro foi relatado com frequência.
18/03/2007 1:08:26 org.apache.tomcat.util.threads.ThreadPool logFull
Grave: Todos os threads (150) estão ocupados, aguardando. Aumente maxThreads (150) ou verifique o status do servlet.
Encontrei algumas respostas online.
1. Acho que alguns de seus recursos não foram liberados e estão paralisados devido ao atraso.
2. Problema no pool de conexões
3. Deve ser causado pelo longo tempo de processamento do thread que responde à solicitação no lado do servidor
:
Havia apenas 2 pessoas usando o site naquele momento, então era impossível que 150 threads simultâneos ficassem online. Portanto, não deve ser um problema de banco de dados.
A julgar pelos prompts de erro, isso deve ser causado pelo uso irracional do pool de conexões ou pelo fato de o pool de conexões não estar configurado. A parte conectada ao banco de dados é conectada usando a fonte de dados JDBC do Spring, conforme segue:
<feijão>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<!-- driver para MySQL-->
<property name="driverClassName"><value>org.gjt.mm.mysql.Driver</value></property>
<property name="url"><value>jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF8</value></property>
<property name="username"><value>teste</value></property>
<property name="password"><value>teste</value></property>
</beans>
O problema deve ocorrer com o DriverManagerDataSource do Spring, que é responsável por gerenciar essas conexões.
A seguir está uma explicação de DriverManagerDataSource
DriverManagerDataSource no Spring Framework
javax.sql Interface DataSource
Implementação de SmartDataSource que configura um driver JDBC simples e antigo via
propriedades do bean e retorna uma nova conexão sempre.
Útil para ambientes de teste ou independentes fora de um contêiner J2EE.
como um bean DataSource em um respectivo ApplicationContext ou em conjunto com
um ambiente JNDI simples. As chamadas Connection.close() que assumem pool serão simplesmente
feche a conexão, para que qualquer código de persistência compatível com DataSource funcione.
Em um contêiner J2EE, é recomendado usar um DataSource JNDI fornecido pelo.
Esse DataSource pode ser exportado como um bean DataSource em um
ApplicationContext via JndiObjectFactoryBean, para alternância perfeita de e para
um bean DataSource local como esta classe
Se você precisar de um conjunto de conexões "real" fora de um contêiner J2EE, considere.
Jakarta Commons DBCP do Apache Seu BasicDataSource é um pool de conexão completo.
bean, suportando as mesmas propriedades básicas desta classe, além de configurações específicas.
Ele pode ser usado como substituto para uma instância desta classe apenas alterando
o nome da classe da definição do bean para
"org.apache.commons.dbcp.BasicDataSource
--------------------------------------
".--------- ----------
Muitos projetos de Jacarta oferecem suporte à interação com um banco de dados relacional.
nova conexão para cada usuário pode ser demorada (muitas vezes exigindo vários
segundos do tempo do relógio), para executar uma transação de banco de dados que possa
levar milissegundos. Abrir uma conexão por usuário pode ser inviável em um momento.
aplicação de Internet hospedada publicamente onde o número de usuários simultâneos pode
Consequentemente, os desenvolvedores muitas vezes desejam compartilhar um "pool" de recursos abertos.
conexões entre todos os usuários atuais do aplicativo O número de usuários.
realmente executar uma solicitação a qualquer momento geralmente é um tempo muito pequeno
porcentagem do número total de usuários ativos e durante o processamento da solicitação é
a única vez que uma conexão com o banco de dados é necessária.
efetua login no DBMS e lida com quaisquer problemas de conta de usuário internamente.
Existem vários pools de conexões de banco de dados já disponíveis, ambos dentro
.
Produtos de Jacarta e outros lugares Este pacote Commons oferece uma oportunidade para
coordenar os esforços necessários para criar e manter um ambiente eficiente,
pacote rico em recursos sob a licença ASF
O pacote commons-dbcp depende do código do pacote commons-pool para fornecer.
os mecanismos de pool de objetos subjacentes que ele utiliza
Os aplicativos podem usar o componente commons-dbcp diretamente ou por meio do componente existente.
interface de seu contêiner/estrutura de suporte. Por exemplo, o Tomcat.
O contêiner de servlet apresenta um DataSource DBCP como um JNDI Datasource James (Java.
Apache Mail Enterprise Server) integrou o DBCP à estrutura Avalon.
A fonte de dados no estilo Avalon é criada agrupando a implementação do DBCP.
lógica de pooling do DBCP e a configuração encontrada no código excalibur do Avalon é
o que era necessário para criar um DataSource confiável e integrado
Depois de ler a explicação, o fato é que ao estabelecer uma conexão, DriverManagerDataSource cria uma nova conexão desde que haja uma conexão e não haja nenhum pool de conexões. Seria melhor mudar para o seguinte pool de conexões de código aberto.
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<nome da propriedade="driverClassName">
<valor>org.hsqldb.jdbcDriver</valor>
</propriedade>
<nome da propriedade="url">
<valor>jdbc:hsqldb:hsql://localhost:9001</valor>
</propriedade>
<nome da propriedade="nome de usuário">
<value>sa</value>
</propriedade>
<nome da propriedade="senha">
<valor></valor>
</propriedade>
</bean>
O teste foi aprovado e o problema foi eliminado. Se não houver um mecanismo de busca para encontrar a resposta, o problema não será resolvido tão rapidamente.