| Autor |
Mensagem |
|
|
Rafael Nunes wrote:No GAE o AlwaysOn mantém 3 instâncias da sua aplicação sempre de pé mesmo sem receber requisições, o que evitaria os 'cold starts'
Legal, é quase a mesma idéia então de se manter X instâncias no mínimo com o AutoScaling.
Só diferencia que no AWS não vai ter esse Cold Start "nunca", pq ele sempre tem uma instância pelo menos no ar, sem baixar a app, mesmo que não tenha requisições.
E quando devido ao AutoScaling ele vai subir outra instância, ele só disponibiliza ela por trás do ELB (balanceador) depois que está pronta para assumir requests.
Rafael Nunes wrote:Me referia a API de serviços(e que pra mim ai está o grande ganho de produtividade no GAE), como: Blobstore, ImageAPI, XMPP, Channel, OpenID, Autenticação com usuários Google/Apps, etc, etc
http://code.google.com/appengine/docs/java/apis.html
Ahh sim, entendi errado, my bad 
|
 |
|
|
Oi pessoal,
Ontem a noite dei uma olhada na documentação, e fiz alguns testes com o Beanstalk. Algumas considerações baseadas na discussão:
pcassiano wrote:1) aplicações 'hospedadas' lá fora, neste caso, 'na nuvem', não demoram mais para carregar, mesmo que alguns 'pentelhésimos' de segundo?
Se vc tiver falando do primeiro acesso, existe sim uma questão no GAE como dito pelo pessoal.
Mas pelo modo que eu li aí, vc tá relacionando mais com a questão de estar "lá fora" do BR, é isso? Se for, de fato alguns pentelhésimos a mais isso leva. Uma app em um host por aqui, tipo Locaweb vai responder mais rápido sim, mas acho que a questão em evidência aqui é muito mais confiabilidade e facilidade que velocidade
bronx wrote:É um lance de performance. O GAE "inativa" a aplicação depois de certo tempo de ociosidade.
Num ambiente como o deles, é inviável o uso "irracional" de recursos. Deixar a app na memória? Só se ela estiver em uso...!
Aí quando vc acessa novamente, leva um tempo sim, pois o GAE tem que subir a aplicação again, recuperar o estado e tal...
É isso aí... essa inativação acontece sim, pra poupar recursos... É nítido o primeiro acesso mais lento. Na última versão do GAE já saiu inclusive documentada essa questão do Warmup Request: http://code.google.com/appengine/docs/java/config/appconfig.html#Warming_Requests parece bem simples fazer isso pra manter a app "quentinha"
Mas eu acho que como disse o Sérgio, o EC2 não faria isso... até pq o EC2 quer te vender a instância, ele não remove tua app da memória, o máximo que ele faz, é diminuir o numero de instancias pra você pagar menos, com base no AutoScaling.
Ontem fiz uns testes tb e já subi uma app tb, feita em Grails, pra quem quiser checar: http://grails-on-beanstalk.elasticbeanstalk.com/
É uma app simples em Grails, com um Domain e scaffold padrão, já tá lá no ar...
Peguei uma instância Micro, com 600mb (tomcat rodando com 44 , e quando mandei o e-mail na lista do Grails, bombou o acesso, o autoscaling funcionou bem, subiu mais uma instância bem rápido, e na madrugada ele derrubou. sozinha...
Sergio Lopes wrote:Eu não testei o Beanstalk ainda mas me parece que eles teriam um problema de Cold Start parecido com o GAE. Você habilita uma instância (ou mais) do EC2 e depois ele vai ativando novas instâncias conforme precisa; e subir essa instância nova deve ser lento também. No GAE hoje você consegue, por exemplo, pagar para deixar 3 instâncias reservadas (AlwaysOn do GAE 1.4), mas se precisar da quarta, vai subir on demand.
O tempo pra subir varia, mas nos meus testes não passaram de 3 minutos, mas você tem como controlar "quando" subir. Se vc descer a métrica do Cloudwatch um pouco, você consegue prever isso e se prevenir!
Não sei muito bem como funciona esse "AlwaysOn" do GAE, mas na infra do AWS AutoScaling e óbvio, agora do Beanstalk, você diz quantas instâncias no mínimo vc quer que fiquem no ar, e quantas no máximo também. Você pode dizer que quer começar com 2 instâncias, pra ter um failover, e ir até 6, dependendo do pico de acesso
Tenho que confirmar certinho, mas se eu não me engano, vc ainda consegue configurar de quanto em quanto elas sobem... Por ex: Começa com duas, vai até 10 no máximo, e vai subindo de duas em duas...
Rafael Nunes wrote:Pontos negativos:
-E principalmente, não tem serviços/APIs prontas como no GAE
Tem sim toda a api pronta já pra acesso! Hoje (quer dizer, desde ontem no lançamento), é possível interagir com o beanstalk de 4 maneiras:
* API Java
* Serviços normais AWS - webservices
* command line da aws - feito em ruby
* console web
* eclipse
Enfim, meus testes foram bem satisfatórios sim, e pra mim que já iria rodar a arquitetura do projeto lá mesmo, com EC2, EBS, ELB, RDS e S3+Cloudfront, acho que não tenho como fugir de uma plataforma como essa aí, no meu caso, vai dar pra ganhar bastante tempo em configuração e deploy.
|
|
|
|
Mark_Ameba wrote:Os safe-null operators sairam mesmo?
Até onde vi tava planejado mas não ia sair.
Isso seria algo muito interessante.
Não gosto de switchs então vou continuar não usando mesmo aceitando Strings.
Sim Mark, vão sair.
[]s,
|
|
|
|
Faltou lembrar do Elvis Operator e do Null-Safe Navigation. (ambos que vieram do Groovy)
O Elvis Operator (Operador Elvis, "está vivo, não morreu, apesar de você não vê-lo") é uma maneira simplificada para usar a atribuição de valores a variáveis com operadores ternários, levando-se em consideração que 90% dos casos onde usamos os operadores ternários, são para validar se um objeto é null ou não. Exemplo.
Já o Null-Safe Navigator, é uma maneira, como dizem os Rubistas e Groovistas (esquisito né), "açucarada" de navegar em objetos e seus filhos. Ele faz uma validação se o objeto onde está se chamando um método é null ou não, para neste caso, efetuar a chamada mesmo.
[]s,
|
|
|
|
Herrera wrote:Lucas,
como foi que voce lembrou do caelum stella ? rs
Herrera
Hehehe, naquela thread mesmo do Grails Brasil
Já havia usado o Stella a um bom tempo, mas lá que acendeu a luz
|
|
|
|
xymor wrote:Muito legal esse plugin Lucas.
Como tu resolveu o problema de registrar o validador com o grails?
Update: Já achei.
Hahahaha, boa!
Pra quem precisa registrar novos validadores, tive que fazer na closure doWithSpring da definição do plugin.
[]s
|
|
|
|
Bom, destrinchando um pouco: Groovy, uma linguagem dinâmica, que roda em cima da JVM, bla bla bla, esse todo mundo conhece: groovy.codehaus.org
Agora, utilizando o Groovy, criaram algumas camadas de abstração para estes frameworks, por exemplo:
 Spring, foi criada uma Spring DSL para facilitar o acesso/configuração/injeção por ele.
Hibernate, foi criado o GORM, que cria todo o mapeamento, validação de constraints, dynamic finders, criterias, etc para acesso as informacoes http://www.grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html
spring mvc, log4j, sitemesh, e para todo o restante envolvido, existem essas DSLs, ou "camadas" facilitadoras do acesso.
Todas estas "abstrações" que foram criadas, formam o framework grails, segunindo a ideologia do rails é claro, de ser um full-stack, de CoC, DRY, etc etc.
Essa é a idéia E seguindo essa linha, a comunidade cria a cada dia mais e mais plugins, que são estas camadas de abstração em cima de algum framework de mercado, por exemplo, <jaba>o plugin do Caelum Stella para o Grails, que abstrai a forma de trabalho do framework adicionando mais constraints as domain classes</jaba>.
Mas não podemos esquecer que Groovy é Java, Grails é Java, tudo que fazemos com Java, podemos fazer com Groovy, ou reaproveitar. Por exemplo, para um projeto em Grails aqui, pegamos todas as libs e jars já desenvolvidas para o cliente no sistema legado e reutilizamos apenas por estarem no lib da app. Classes utilitárias, arquiovos .jave e todo o restante também, se encaixam no projeto como parte dele, sem uma "adaptação" ou retrabalho algum.
|
|
|
|
Oi pessoal,
Precisava de um validador de CPF e CNPJ dentro da minha aplicação, desenvolvida em grails e lembrei do caelum stella.
Acabei criando o plugin grails-stella para aplicações em Grails que insere este tipo de validação como os validadores nativos do framework, para que possam ser utilizados diretamente nas constraints das classes de domínio.
Por enquanto conta com os validadores para CPF e CNPJ (formatados ou não), como recurso futuro, dá pra embutir também os formatadores e até quem sabe os Boletos depois.
Página do plugin no github: http://github.com/lucastex/grails-stella
Wiki do plugin com exemplos, links e documentação: http://wiki.github.com/lucastex/grails-stella
Exemplo de uso em uma domain class, simples assim:
Com isso, a classe utilizará o plugin (que por sua vez usa o Stella) para validar o CPF (neste caso, formatado) e CNPJ antes de salvar o objeto em database e etc.
Até mais,
[]s,
|
|
|
|
Eu uso bastante, e recomendo!
Pra quem gosta do assunto, tenho um blog onde falo sobre Groovy e Grails: http://blog.lucastex.com
[]s,
|
|
|
|
Oi,
Eu particularmente uso o Groovy em tasks de script mesmo, fora de uma aplicaçao.
Por exemplo, para algumas rotinas ou scripts que tinhamos externos a aplicaçao, em .sh mesmo, agora optamos pelo groovy, que e bem facil, todo desenvolvedor java tem condiçao de fazer, e ainda temos a grande facilidade de (como eh java), usar qualquer lib de dependencia.
[]s,
|
|
|
|
renatafurlan wrote:Olá Pessoal,
Vou precisar utilizar Timer Event Generators do BEA Weblogic Integration 8.1 SP6.
Alguém já utilizou esses eventos ou já encontrou algum problema em utilizá-los..
Grata
Oi Renata,
Usei ja sem problemas os Event Generators do Weblogic. Tanto Timers, quanto File, JMS, etc.
Pode ir sem problemas.
[]s,
|
|
|
|
Resolvido.
Infelizmente não da melhor maneira.
Para usar Jax-Ws, o Oracle Service BUS não dá suporte para chamada de web-services assíncronos, então, a opção fica descartada.
Para usar Jax-Rpc, com SOAP/JMS existe um BUG no Weblogic que retira as mensagens de forma serializada, ou seja, uma por vez, fazendo com que não seja possível ter paralelismo na operação, então opção também descartada.
Tivemos que implementar o transporte JMS do Oracle Service Bus ao Weblogic e colocar MDBs na ponta para efetuar as operações. A resposta foi feita usando JMS Request Response com o pattern Message Id.
Obrigado,
[]s,
|
|
|
|
DaviPiala wrote:Eu sei de uma solução sombria, só que é tão horrivel que nem vou comentar.
O serviço está exposto com foco em reusabilidade? Ele irá ter diversos clientes?
Sim. E com mais de um endpoint disponível.
Tanto em HTTP quanto em JMS, @HttpTransport e @WlJmsTransport...
Qual a idéia?
[]s,
|
|
|
|
DaviPiala wrote:Eu sei de uma solução sombria, só que é tão horrivel que nem vou comentar.
Solução sombria? Nem comente aqui por favor....
Mas talvez você queira comentar ela por e-mail
|
|
|
|
Bom,
Respondendo a questão de jax-ws, de fato o Oracle Service BUS não suporta chamada assíncronas para ele.
Acabei de ser respondido no fórum da Oracle sobre isto: http://forums.oracle.com/forums/thread.jspa?threadID=904971.
Resta agora apelar para alguma maneira menos tradicional de se colocar com jax-rpc.
[]s,
|
|
|
|
|
|