Comments on: Java continuations e NIO, o casamento perfeito http://www.kumpera.net/blog/index.php/2006/10/12/29/ Meus achados sobre tecnologia Thu, 02 Sep 2010 20:00:29 +0000 http://wordpress.org/?v=2.8.6 hourly 1 By: felipe http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-672 felipe Tue, 07 Nov 2006 19:33:31 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-672 Rodrigo, gostaria de entender melhor o objetivo de usar i/o não bloqueante com continuations na leitura e escrita dos channels, já que o i/o não bloqueante já meio que funciona como se tivesse continuation (é lido o que está disponivel, mesmo que essa leitura precise continuar depois e o mesmo vale para escrita). Se não existem dados para ler, qual o sentido de eu suspender o processamento? Qual o ganho real dessa suspensao(usando continuations) se o i/o não é bloqueante? (ou seja, o thread continua executando outras coisas ao invés de ficar parado) Rodrigo,

gostaria de entender melhor o objetivo de usar i/o não bloqueante com continuations na leitura e escrita dos channels, já que o i/o não bloqueante já meio que funciona como se tivesse continuation (é lido o que está disponivel, mesmo que essa leitura precise continuar depois e o mesmo vale para escrita).

Se não existem dados para ler, qual o sentido de eu suspender o processamento?

Qual o ganho real dessa suspensao(usando continuations) se o i/o não é bloqueante? (ou seja, o thread continua executando outras coisas ao invés de ficar parado)

]]> By: kumpera http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-574 kumpera Wed, 18 Oct 2006 15:31:21 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-574 Willian, eu já utilizei antes o Apache MINA. A arquitetura é boa e o software é de estavel. O grande problema é o inferno que é programar codecs e afins.<br> Com MINA você escreve basicamente 2 componentes, o (de)codicador de mensagens e o tratador de mensagens. O primeiro é responsavel por traduzir de/para o formato de rede (de stream para ServletRequest, por exemplo); o segundo lida apenas com objetos da aplicação e possui as regras de negocios, por assim dizer.<br> Implementar um codec é exponencialmente dificil em relação a complexidade do protocolo, e de quao eficiente você quer que ele seja. É basicamente implementar uma máquina de estados enorme. Já fiz para HTTP 1.1 parcialmente e conheci o inferno.<br> Depois vem o protocol handler, ele tem que se preocupar com coisas como flow control, para não mandar dados rápido demais e deixar um toneladas de buffers na mão do framework. Fora que você tem que programar utilizando um modelo orientado a eventos. Uma delicia. Willian, vou mostrar num artigo futuro então a diferença de dificuldade com um protocolo não trivial.<br> Willian, eu já utilizei antes o Apache MINA. A arquitetura é boa e o software é de estavel. O grande problema é o inferno que é programar codecs e afins.

Com MINA você escreve basicamente 2 componentes, o (de)codicador de mensagens e o tratador de mensagens. O primeiro é responsavel por traduzir de/para o formato de rede (de stream para ServletRequest, por exemplo); o segundo lida apenas com objetos da aplicação e possui as regras de negocios, por assim dizer.

Implementar um codec é exponencialmente dificil em relação a complexidade do protocolo, e de quao eficiente você quer que ele seja. É basicamente implementar uma máquina de estados enorme. Já fiz para HTTP 1.1 parcialmente e conheci o inferno.

Depois vem o protocol handler, ele tem que se preocupar com coisas como flow control, para não mandar dados rápido demais e deixar um toneladas de buffers na mão do framework. Fora que você tem que programar utilizando um modelo orientado a eventos. Uma delicia. Willian, vou mostrar num artigo futuro então a diferença de dificuldade com um protocolo não trivial.

]]> By: Willian Mitsuda http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-573 Willian Mitsuda Wed, 18 Oct 2006 15:15:03 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-573 Rodrigo, vc chegou a estudar a possibilidade de usar o Apache MINA? Se entendi bem o seu problema, acho que ele já implementa toda a infra que vc precisa, só precisando implementar um codec p/ o seu protocolo. http://directory.apache.org/subprojects/mina/index.html Rodrigo, vc chegou a estudar a possibilidade de usar o Apache MINA?

Se entendi bem o seu problema, acho que ele já implementa toda a infra que vc precisa, só precisando implementar um codec p/ o seu protocolo.

http://directory.apache.org/subprojects/mina/index.html

]]> By: Luca Bastos http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-557 Luca Bastos Tue, 17 Oct 2006 13:54:31 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-557 Agora que o Gilad Bracha saiu da Sun, fui ler o antigo blog dele na Sun e o encontrei falando de continuantions. Lembrei logo de ti. Não ainda não leu, dê uma lida em: http://blogs.sun.com/gbracha/entry/will_continuations_continue http://blogs.sun.com/gbracha/entry/continuations_continued Agora que o Gilad Bracha saiu da Sun, fui ler o antigo blog dele na Sun e o encontrei falando de continuantions. Lembrei logo de ti.

Não ainda não leu, dê uma lida em:
http://blogs.sun.com/gbracha/entry/will_continuations_continue
http://blogs.sun.com/gbracha/entry/continuations_continued

]]> By: Rodrigo Urubatan http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-551 Rodrigo Urubatan Thu, 12 Oct 2006 23:18:50 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-551 isto é verdade :D e parece que estou mal informado :D acreditei na propaganda do jetty, e achava que ele estava usando NIO para tudo :( isto é verdade :D
e parece que estou mal informado :D
acreditei na propaganda do jetty, e achava que ele estava usando NIO para tudo :(

]]> By: kumpera http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-548 kumpera Thu, 12 Oct 2006 17:19:53 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-548 Jetty não resolve meu problema. Beeem longe disso. Jetty tem um treco que alega "suportar continuations", mas na verdade é um mecanismo pelo qual você tem que implementar o suspend/restore manualmente, ou seja, tem uso super-super específico: comet. Além disso, o jetty funciona usando threading e I/O bloqueante para todo o resto, o que não resolve meus problemas de escalabilidade. Para terminar, não adianta eu ter um servidor escalavel se eu vou continuar esbarrando no driver JDBC. Jetty não resolve meu problema. Beeem longe disso.
Jetty tem um treco que alega “suportar continuations”, mas na verdade é um mecanismo pelo qual você tem que implementar o suspend/restore manualmente, ou seja, tem uso super-super específico: comet.

Além disso, o jetty funciona usando threading e I/O bloqueante para todo o resto, o que não resolve meus problemas de escalabilidade. Para terminar, não adianta eu ter um servidor escalavel se eu vou continuar esbarrando no driver JDBC.

]]> By: Rodrigo Urubatan http://www.kumpera.net/blog/index.php/2006/10/12/29/comment-page-1/#comment-547 Rodrigo Urubatan Thu, 12 Oct 2006 16:48:35 +0000 http://www.kumpera.net/blog/index.php/2006/10/12/29/#comment-547 ótima a solução, mas tu tem problemas :D não era mais fácil usar o jetty em vez de implementar isto novamente? ótima a solução, mas tu tem problemas :D
não era mais fácil usar o jetty em vez de implementar isto novamente?

]]>