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 MXML puro com RemoteObject chamando o destination disparando todas as > requisições de uma vez > > o comportamento se repete nesse caso tambem =/ > > > > > > Em 21 de dezembro de 2010 11:00, Erko Bridee de Almeida Cabrera < > erko.bri...@gmail.com> escreveu: > > não tem não hehe >> >> é a primeira vez que eu me deparo com uma situação dessas onde eu disparo >> multiplas requisições para o mesmo destination >> >> onde tenho uma tela com vários gráficos gauge e no destination (classe >> java mapeada) cada método retorna um respectivo valor para cada >> >> até onde debuguei e estou testando, ele lança todas as requisições, as >> quais caem na mesma thread de processamento de uma request HTTP no servidor, >> até parece que foi recebido um array de requisições... >> >> então o processamento é executado sequencial, com isso somente no termino >> de todos as requisições recebidas é que os resultados retornam para o flex >> >> -- >> >> a principio cada requisição do RemoteObject pela definição inicial era >> para abrir uma thread de processamento HTTP no servidor java, o que não está >> acontecendo no caso >> >> o pior que não acho nada do assunto na internet hehe >> >> >> >> >> Em 20 de dezembro de 2010 15:35, fabiophx >> <fabiophx2...@yahoo.com.br>escreveu: >> >> Erko, >>> As 8 requisições estão sendo disparadas? E só o retorno está vindo >>> em sequência? Do teu lado java não tem nenhum método em comum marcado >>> como syncronized (acho q é assim a escrita) esta marcação permite q >>> somente uma thread de cada vez execute o método. >>> >>> []s >>> Fabio da Silva >>> http://www.fabiophx.blogspot.com/ >>> >>> On Dec 20, 11:46 am, Erko Bridee de Almeida Cabrera >>> <erko.bri...@gmail.com> wrote: >>> > Olá pessoal, >>> > >>> > estou apanhando do swiz no respectivo cenário: >>> > >>> > tenho uma aplicação estilo dashboard onde em uma tela tenho 8 gráficos >>> que >>> > irão disparar >>> > 8 requisições quando esta tela for carregada >>> > >>> > estou me deparando com um comportamento onde cada requisição e sua >>> resposta >>> > estão executando >>> > sequencialmente >>> > >>> > *obs.:* as requisições destas 8 janelas passam por um mesmo Controller, >>> e no >>> > java tenho 1 classe >>> > com 8 métodos para cada um dos gráficos >>> > >>> > alguem já teve esse "problema"? >>> > >>> > aceito sugestões e links de referencias de material >>> > >>> > *obs.2: *já estou a 2 dias testando tudo que é alternativa que me vem a >>> > mente e também estou procurando no google e documentações, até agora >>> não >>> > consegui fazer com que as requisições funcionem como eram para ser no >>> Flex, >>> > assincronas e concorrentes :P >>> > >>> > -- >>> > 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 >> >> >> >> >> -- >> 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 >> > > > > -- > 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 > -- 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
