Caramba... to pior q bebado aki estou revisando o fluxo de execução dentro do blazeds agora...
verifiquei que a requisição recebida no BlazeDS dentro da Classe: flex.messaging.endpoints.amf.BatchProcessFilter método: invoke o parametro recebido: ActionContext context seu respectivo número de mensagens o valor é o mesmo da quantidade de requisições que eu disparei no Flex e o atributo: requestMessage.bodies possui a quantidade e referências dos processamentos solicitados... nessa classe BatchProcessFilter ele faz um loop nesses bodies... por isso que tudo é processado de uma vez no lado do java e depois retorna tudo junto... segue a descrição do fluxo do processamento no BlazeDS até chegar a classe mapeada no destination: 1 - flex.messaging.MessageBrokerServlet ( linha:353 ) 2 - flex.messaging.endpoints.BaseHTTPEndpoint ( linha:291 ) 3 - flex.messaging.endpoints.amf.SerializationFilter ( linha:166 ) 4 - flex.messaging.endpoints.amf.BatchProcessFilter ( linha:67 ) ** nessa classe possui o loop ** 5 - flex.messaging.endpoints.amf.SessionFilter ( linha:44 ) 6 - flex.messaging.endpoints.amf.LegacyFilter ( linha:158 ) 7 - flex.messaging.endpoints.amf.MessageBrokerFilter ( linha:103 ) 8 - flex.messaging.endpoints.AbstractEndpoint ( linha:1005 ) 9 - flex.messaging.MessageBroker ( linha:1400 ) 10 - flex.messaging.services.RemotingService ( linha:183 ) 11 - flex.messaging.services.remoting.adapters.JavaAdapter 12 - [ Classe Java mapeada no destination ] depois realiza o caminho inverso -- bom como vi que no BlazeDS ele recebeu em 1 única requisição dentro do objeto, todas as requests encapsuladas, agora tenho que descobrir pq diabos o Flex está unindo em uma request pois até onde já usei esta é a primeira vez que observo esse comportamento :P *sinistro *hehe Em 21 de dezembro de 2010 14:25, Mário Júnior <juninho...@gmail.com>escreveu: > 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 > -- Att, Erko Bridee de Almeida Cabrera *TechDev : *http://blog.erkobridee.com/ *Gospel : *http://gospel.erkobridee.com/ *Twitter : *http://twitter.com/ErkoBridee *Currículo : *http://netcarreiras.com/prof.html?uid=11410 -- 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
