Yoplà,
 
Voilà, je voudrais browser une queue, mais en recevant les messages les plus récents en premier. (Sachant que l'idée est aussi de faire du paging, donc de lire les messages 20 par 20, par exemple)
 
Si j'ai un bete queue browser, l'Enumeration qui m'est retournée contient forcément les messages les plus anciens en premier.
 
Si qqun à une idée de génie, je suis preneur.
 
(on me propose dans l'oreille d'utiliser un selecteur sur la delivery-date, du genre sur le "jour courant", puis de descendre jour par jour jusqu'a remplir mon array de 20 messages... un peu pas propre, et pas safe si un "jour" est coupé entre 2 pages)
 
J'écoute  

question con : il se passe quoi si après avoir retiré le message le plus récent, un nouveau message arrive ? tu veux traiter le nouveau plus récent ou l'ancien deuxième plus récent ?

On s'en fout, c'est une vue non transactionnelle.

ça n'empêche pas qu'il faut choisir.
 
Mais si vous vous en foutez vraiment, vous foutez le tout dans un arraylist et vous le parcourez à l'envers. Vous recyclez l'arraylist (l'*instance* de l'ArrayList ) pour pas trop faire des allocations de gros objets.

 
la private joke puante

 
euh on s'en fout pas de fouttre 6000 messages dans une arraylist, la renverser pour aller lire 20 messages quoi
 
C'est pour ça que je suggère un système de caching. Meme si c'est un peu crade, ca peut etre totalement caché et validé par des test cases. M'enfin moins moins n'a pas l'air fan

Elle est très bien ma blague je trouve.
 
 
ça va aller une arraylist 6000 éléments ? ça fait un objet de 24ko. Puis il peut la "couper" avec un sélecteur s'il veut.
 
Enfin, s'il n'y a que les brouteurs pour examiner une queue sans recevoir les messages, y'a forcément une bidouille (et des assertions à la con).

bin oui il peut la couper. C'est bien ce que je lui suggère mais il n'est pas fan.

ouais, bah il va se faire foutre avec son pb alors.
 
Il a une interface avec 4 fonctions et il veut faire un truc sémantiquement incorrect, qu'il s'attende pas à un truc super fin et intelligent et à en plus trouver des fonctions toutes faites dans la norme.

han 8 réponses

 
le but c'est justement d'éviter si possible la lecture des 408502messages qui sont dans ma queue

ça fait 24ko dans le cas ou les messages que je récupère dans ma queue sont déjà chargés. *IL SE TROUVE* que c'est le cas dans l'implementation actuelle de jboss, mais je suis pas supposé le savoir, et ça devrait changer (un jour)... donc le jour ou ça change effectivement, je me retrouve comme un con à faire charger ces 203830 messages pour rien.

ça a déjà été répondu.

et puis c'est pas à toi que je vais apprendre comment on fait dans la vraie vie quand on a un pb comme ca ...

ouais mais non

j'ai pas trouvé la javadoc spécifique à l'implémentation JBOSS de JMS, je me suis fait noyer par google, vous l'avez ?

non , mais à priori ce que je disais sur l'impl de jbossmq, je le tiens de dark qui à mon avis l'a vu dans le code

je l'ai vu dans le code effectivement et aussi sur le forum, vu que ceux qui browse une queue d'1 million de messages sont bien emmerdés. La logique voudrait que ce soit une Enumareation "dynamique" qui soit retournée, un peu comme un resultset mais non

voilà. et le jour ou j'ai un million de msg dans ma queue, j'ai pas envie de tout balancer dans une arraylist avant de la retourner