[Design of POJO Server] - Re: JBAS-6061 or weird nested jar
by alesj
"adrian(a)jboss.org" wrote :
| It's only referenced by the VFS because the JarStructure is adding it as a
| subdeployment.
No, that's not the case here. ;-)
If you look at the actual JIRA issue,
you'll see that Luc has added it to server/some-as-config/lib
- as that's how/why conf/jboss-service.xml is able to see it in its classpath -
meaning it's referenced via this piece of xml (from jboss-service.xml):
| <server>
|
| <!-- Load all jars from the JBOSS_DIST/server/<config>/lib directory. This
| can be restricted to specific jars by specifying them in the archives
| attribute.
| -->
| <classpath codebase="${jboss.server.lib.url:lib}" archives="*"/>
|
Being added to conf/jboss-service.xml as part of its classpath in SARDeployer::processXMLClasspath.
Hence the actual jar is checked/read in some CL impl details,
no way to add some flag and ignore it if it's broken.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182157#4182157
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182157
17 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation
by timfox
"ataylor" wrote :
| So first the PriorityLinkedList implementation will be changed to use ConcurrentLinkedQueue's instead of Lists. Doing this means that the server consumer can iterate over the queue without a comod exception being thrown. The only drawback is we can't add to the head so for now i'm just making a clone of the list.
|
I couldn't figure out from this if you're changing the implementation or just making a clone, since you say you're doing both in the same paragraph ;)
anonymous wrote :
| All browsing will be done using current consumer functionality. I'll add a new flag to specify what kind a consumer is, i.e. a browser or not. If a Consumer is a browser the it will not add itself to the queue to receive messages, instead it will iterate over the whole queue sending messages until there are no more.
How does this work with flow control? What if the consumer buffer is full before it has iterated the entire queue?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182138#4182138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182138
17 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation
by ataylor
A bit more info on what I'm doing:
So first the PriorityLinkedList implementation will be changed to use ConcurrentLinkedQueue's instead of Lists. Doing this means that the server consumer can iterate over the queue without a comod exception being thrown. The only drawback is we can't add to the head so for now i'm just making a clone of the list.
All browsing will be done using current consumer functionality. I'll add a new flag to specify what kind a consumer is, i.e. a browser or not. If a Consumer is a browser the it will not add itself to the queue to receive messages, instead it will iterate over the whole queue sending messages until there are no more and then notify the client consumer, the caveat here being the normal flow control methods. The client consumer will just read messages of its internal buffer until it is notified that there is none left. Doing it this way means a browser has the performance of normal consumer for the sake of just a couple of extra methods added, we also now see changes to the queue rather than just a static snapshot. It also means we can delete all the browser classes as they are not needed any more.
One problem that we have is to do with paging. Since messages are never routed to the queue until they are depaged a browser will never be able to browse over all messages once paging has occurred. But this is no different to what we have now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182135#4182135
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182135
17 years, 5 months