RPC - Procedimentos Remotos

Na minha opinião, para saber aonde melhorar, você deve saber aonde é preciso melhorar. Por isso, use um profiler, encontre aonde estão os gargalos.

Sobre o Quartz, não acho que ajude no teu caso. Thread me parece ser mais adequado.

pozzo:

Na minha opinião, para saber aonde melhorar, você deve saber aonde é preciso melhorar. Por isso, use um profiler, encontre aonde estão os gargalos.

Sobre o Quartz, não acho que ajude no teu caso. Thread me parece ser mais adequado.

meus gargalos são justamente as threads, queria usar outra solução algo mais robusto, e essas procedures remotas não se aplica ao caso ?

eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?

não sei se intendi direito…

maior_abandonado:

eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?

não sei se intendi direito…

a resposta é sim, mas a empresa que trabalho hoje tem uma arquitetura própria, e um framework próprio que eu mesmo ajudo no desenvolvimento, mas se for pensar em usar EJB ou não, no que isso implicaria ? aonde estão os ganhos ? o que facilitaria ? o que justificaria eu migrar de uma aplicação desse porte para o EJB ?

Bom, incialmente você poderia tentar usar um pool de conexões, para gerênciar melhor suas conexões com o banco de dados.

Também poderia verificar se as api de leitura de arquivos está sendo usada corretamente. Trocar algumas classes para nio, caso não esteja usando.

Outro ponto é que as vezes o teu hardware pode estar no limite. Talvez pensar em melhorar ele. Fazer um cluster, etc.

Eu siceramente não acredito que sejam as “Threads”, mas sim I/O dentro delas.

Sobre RPC, ou RMI (implementação Java), é para fazer computação distribuída. Talvez pensar em alguma implementação para distribuir esse processamento em várias máquinas, que é o caso do cluster que foi sugerido.

maior_abandonado:

eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?

não sei se intendi direito…

O EJB seria uma opção, se fosse permitido ler arquivos com ele. A especificação diz que não se deve fazer isso, pois é o container deve gerênciar todos os recursos, acessos a dados, threads, etc.

pozzo:

maior_abandonado:

eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?

não sei se intendi direito…

O EJB seria uma opção, se fosse permitido ler arquivos com ele. A especificação diz que não se deve fazer isso, pois é o container deve gerênciar todos os recursos, acessos a dados, threads, etc.

legal cara, interessante saber disso.

bom… o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.

Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo…

maior_abandonado:

bom… o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.

Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo…

Perfeito, as considerações sobre EJB estão corretas.

Quanto as restrições, você não deve fazer. Mas você consegue… O container pode ter mal funcionamento, é um risco que você vai correr.

http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html

maior_abandonado:

bom… o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.

Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo…

eu acredito que possa facilitar a vida sim, quando se sabe bem EJB, que não é meu caso, não que eu tenha algum problema em aprender novas técnologias mas para eu alterar a técnologia de um sistema grande aqui na empresa que trabalho, teria eu que ter um bom argumento e ainda mostrar o que o EJB faz que a aplicação não faz hoje sem o uso dele, o que não consegui ver, eu ainda acredito que tenha outras opções alem da threads mas ainda não sei quais são. o problema de sincronização foi resolvido ja, o meu maior problema hoje ainda é com o SQL Server em fazer um delete cascade com referência na mesma tabela, usei outra solução, em 1 semana de teste uma das tabelas de log chegou a 2 giga mas isso é um outro rolo que vamos resolver colocando essas tabelas especifica por banco de dados, ja que são muitos bancos e hoje fica em um principal que todos outros bancos utilizam, queria eu entender de arquitetura a fundo para então dar o melhor nesse e em outros softwares, obrigado por responder amigo, abraços.

Na verdade, vc tem várias opções interessantes:

1. JMS;
2. Spring Batch;
3. Apache Camel;

Só analisar os pontos de cada um e ver quais são interessantes para vc, OK?

[]´s

asaudate:

Na verdade, vc tem várias opções interessantes:

1. JMS;
2. Spring Batch;
3. Apache Camel;

Só analisar os pontos de cada um e ver quais são interessantes para vc, OK?

[]´s

obrigado, olhei a documentação dos 3 e o que mais se encaixa com o que procuro é o Spring Batch, vou ler a documentação a fundo e me certificar se vale a pena investir nele, antes de começar a migrar uma app grande, abraços velho, e obrigado.

Oi aix.

Também não sou nenhum expert no assunto mas se o problema é a sobrecarga de dados na rede, já pensou em utilizar agentes ou agentes móveis?

Fiz um sistema (não profissional) em que utilizei agentes móveis e o resultado foi muito bom. Meu sistema tinha desempenho infinitamente melhor do que se eu utilizasse rpc pois as requisições na rede chegavam aos milhões. Acho que rpc em casos que existe possibilidade de ocorrer latência na rede nao é tão recomendado. Vale a pena dar uma olhada nos agentes, movéis ou não. Recomendo em Java, o Jade (mais profissional) e Aglets(mais fácil de implementar), porém existem outros e até em outras linguagens

dio.msg:

Oi aix.

Também não sou nenhum expert no assunto mas se o problema é a sobrecarga de dados na rede, já pensou em utilizar agentes ou agentes móveis?

Fiz um sistema (não profissional) em que utilizei agentes móveis e o resultado foi muito bom. Meu sistema tinha desempenho infinitamente melhor do que se eu utilizasse rpc pois as requisições na rede chegavam aos milhões. Acho que rpc em casos que existe possibilidade de ocorrer latência na rede nao é tão recomendado. Vale a pena dar uma olhada nos agentes, movéis ou não. Recomendo em Java, o Jade (mais profissional) e Aglets(mais fácil de implementar), porém existem outros e até em outras linguagens

obrigado por responder amigo, meu problema maior até não é a sobrecarga, e sim as threads mesmo que não me soa bem usa-las, mas enfim vou dar uma olhada nesses agentes móveis pois desconheço o assunto, meu esquema é java mesmo, eu to estudando o Spring Batch que o amigo Asaudate citou acima, pelo que ja li dele parece se encaixar bem no sistema que estou trabalhando, final de semana ja devo implementar algo com ele, obrigado.