Sim, ele poderia Michel.. e na verdade é oq já está acontecendo, mas não é oq ele quer.
Veja bem, tentando resumir a história até para clarearmos melhor a idéia: - Por toda vida soubemos que as requisições são assíncronas. - Mas no caso do Erko, ele está disparando 8 requisições para o mesmo destination (a mesma classe, mas métodos diferentes) - Em tese, cada retorno independe do outro, certo? Pois não é isso q está acontecendo... a requisição 8 só volta após o processamento da 7 for concluida, e essa após a 6, e dessa a 5, assim por diante. Ou seja, já está *síncrono* e não *assíncrono*, como todos esperam. Por isso q eu acho q é um "bug" ou um "comportamento correto, mas não documentado" do BlazeDS. A Factory cria apenas um objeto RemotingService (já q todas as requisição apontam para a mesma classe do back-end), e então consome os métodos 'em ordem', mas erroneamente segundo sua própria documentaçao os objetos são criados por request... enfim, to achando melhor classificar isso como um bug mesmo. []s Em 21 de dezembro de 2010 14:12, Michel Fernandes <miche...@gmail.com>escreveu: > Vc nao pode chamar no final/result de cada requisicao a proxima, > cascateando? > > Em 21/12/2010 13:33, "Mário Júnior" <juninho...@gmail.com>escreveu: > > > Oq comprova q o problema não tem relação com o swiz diretamente. > > Conforme nossa conversa ontem, acho q pode ser uma das duas coisas (ou as > duas juntas, hehe): *Bug na Factory do BlazeDS.* > > A documentação diz claramente que um RemotingService (objeto que encapsula > seu destination - a sua classe de serviço) é criado com um scope "request" > por default. Ou seja, *para cada request um novo objeto de serviço é > criado*. Como são 8 requisiçoes, logo deveríamos ter 8 objetos diferentes, > mas não é isso oq acontece de fato. Pelo comportamento q vc me disse ontem, > me parece q a Factory cria apenas 1 objeto e então executa os métodos > um-a-um, tornando o processo síncrono. > > Portanto, precisamos ver se isso é um bug mesmo, ou um comportamento "nao > documentado". Por um lado é até bom não criar 8 instancias do mesmo objeto > no servidor - poupa memória e processamento - mas ao menos isso poderia > ficar mais claro na documentação. > > > Vc chegou a fazer aquele outro teste que sugeri? Um método em outra classe > ... coloque um thread.sleep nesse metodo e chame os outros 7 da primeira > classe, só pra ver se o processamento seguirá em threads diferentes (agora q > se tem 2 destinations diferentes) > > > []'s > > > > > > > > Em 21 de dezembro de 2010 11:02, Erko Bridee de Almeida Cabrera < > erko.bri...@gmail.com> escreveu: > > > > > > Ah para completar... > > > > conversando com o Mario Junior, ele sugeriu um teste isolado: > > > > 1 MX... > > > > > -- > Mario Junior > http://blog.mariojunior.com/ > @mariojunior > > -- > > Você recebeu esta mensagem porque está inscrito na lista "flexdev" > Para enviar uma mensagem, envie u... > > -- > Você recebeu esta mensagem porque está inscrito na lista "flexdev" > Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com > Para sair da lista, envie um email em branco para > flexdev-unsubscr...@googlegroups.com > Mais opções estão disponíveis em http://groups.google.com/group/flexdev > -- Mario Junior http://blog.mariojunior.com/ @mariojunior -- Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com Para sair da lista, envie um email em branco para flexdev-unsubscr...@googlegroups.com Mais opções estão disponíveis em http://groups.google.com/group/flexdev
