Bom.. se o Flex já manda tudo numa request só é mais estranho ainda ... Se for assim, começa a procurar no framework pela classe AbstractInvoker ... é ela quem "dispara" as requisicoes... dá uma olhada no fonte.
[]'s e boa sorte com essa caçada :) Em 21 de dezembro de 2010 15:12, Erko Bridee de Almeida Cabrera < [email protected]> escreveu: > 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 <[email protected]>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 >> <[email protected]>escreveu: >> >> Vc nao pode chamar no final/result de cada requisicao a proxima, >>> cascateando? >>> >>> Em 21/12/2010 13:33, "Mário Júnior" <[email protected]>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 < >>> [email protected]> 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 [email protected] >>> Para sair da lista, envie um email em branco para >>> [email protected] >>> 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 [email protected] >> Para sair da lista, envie um email em branco para >> [email protected] >> 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 [email protected] > Para sair da lista, envie um email em branco para > [email protected] > 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 [email protected] Para sair da lista, envie um email em branco para [email protected] Mais opções estão disponíveis em http://groups.google.com/group/flexdev
