November 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Why do Topic/Queue descriptors need extra metadata in or

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The further idea was that xml definitions for these plugins would be written | which would mean in the jboss-messaging deployment we could add some | xml to define their MO definitions. | Even without the xml, it should be possible to write a simple bean that can be deployed to the MC to do this as a "quick fix". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191177#4191177 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191177

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Why do Topic/Queue descriptors need extra metadata in or

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | "charles.crouch(a)jboss.com" wrote : | | c) Can we supply this annotation as some sort of cross-cutting concern? i.e. all instances of org.jboss.jms.server.destination.QueueService created by the MC need to have this annotation applied. I'm fine with having another *single* deployment descriptor which we would ship with that defines this, as opposed to getting users to update *every* destination descriptor they have. | | | This should be doable via the metadata repository using a loader that adds this annotation for specific mbean types. This could also be done by changing the ServiceMetaDataICF, probably other ways. | The original idea was that all these factories (ManagedObject/MetaType/MetaValue) contain overridde mechainsms. So for example you can add a ManagedObjectBuilder by class to the ManagedObjectFactory. The further idea was that xml definitions for these plugins would be written which would mean in the jboss-messaging deployment we could add some xml to define their MO definitions. This is necessary because although we can ask other jboss projects to annotate their (m)beans for management, they might refuse, do it wrong or it might not be a jboss project. So we need a way to retrofit or fix the managed object description. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191176#4191176 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191176

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: comments on initial xsd jpdl 4

by kukeltje

"thomas.diesler(a)jboss.com" wrote : Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way. | | GPD concerns should not leak into the jPDL XSD Funny, this latter remark is a 180 degree turn from what was initially the idea. Making one jpdl file with process and graphical info in it instead of having to keep two files in sync. The 'general extension machanism' is using good extensionpoints in the xsd. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191166#4191166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191166

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: API first cut available for jBPM3

by thomas.diesler＠jboss.com

ok, I'll incorporate your comments View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191164#4191164 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191164

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: comments on initial xsd jpdl 4

by kukeltje

"tom.baeyens(a)jboss.com" wrote : we discussed exactly the topic element vs attribute a full hour yesterday. and we swinged back and forth between element and attribute. | | we looked into various bpmn modellers to see what kind of information they had apart from the | * diagram size | * activity box bounds coordinates, width and height | * transition/flow anchor points and bendpoints | Where is this info going then? "tom.baeyens(a)jboss.com" wrote : does this reasoning make sense to you as well ? No, since it does not say where the other info is going.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191163#4191163 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191163

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: comments on initial xsd jpdl 4

by thomas.diesler＠jboss.com

Yes, a general extension mechanism should be put in place that allows the GPD and other consumers of the jPDL to extend the definition in an appropriate way. GPD concerns should not leak into the jPDL XSD View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191161#4191161 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191161

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Paging code review

by timfox

As discussed in our code review yesterday, here are the outstanding issues in paging that need to be addresses. Some should already be covered in JIRA tasks. If the others don't have JIRAs they need to be covered by at least one, if not fixed immediately. 1. Use OrdereredExecutorFactory for thread management. This should make the global pager redundant. 2. We should ignore corrupt pages on load, and log a clear warning in the logs so the user can address the issue. 3. Much of the functionality currently in PagingManagerImpl is better placed in PagingStoreImpl, e.g. addSize, ondePage. This would also simplify the code since less lookups would be needed and several methods could be removed or made private. 4. PagingStoreImpl - The locking is very complex. Can this be simplified by using Condition objects with the lock? Or perhaps we can disallow concurrent writes to the same page - which would simplify the locking. IS there really much performance to be gained by concurrent writes to the same page? Can this be verified with a test? 5. PagingStoreImpl: if (returnPage.getNumberOfMessages() == 0) How can number of messages in a page be zero? Clebert to check 6. PagingStoreImpl::page() Calculation of block size and lock acquisition: int bytesToWrite = fileFactory.calculateBlockSize(message.getEncodeSize() + PageImpl.SIZE_RECORD); // The only thing single-threaded done on paging is positioning and // check-files (verifying if we need to open a new page file) positioningGlobalLock.acquire(); Can this be *after* the currentPage check - since in 99% of cases paging is not occurring and we don't want to get locks / do calculations unnecessarily. 7. PagingStoreImpl::page pagedUsedSize is being incremented twice? 8. TransactionImpl: An address can switch from paging to not paging mid way during a transaction before it is committed, resulting in the transactions messages being routed out of order 9. TransactionImpl: Currently paged messages are paged on commit(). If there are a lot of paged messages this could hold up the remoting thread for a significant amount of time, One of the design principles of the server is each operation should be quick to complete to avoid starving other operations.l We should consider instead, writing transactional actions straight to a file in the paging case, then on commit, since we know they are on file we can process them on a different thread and the commit can return ok immediately. This would also allow us to deal with huge transactions, much bigger than can fit in memory at once 10. Currently routing code is duplicated in ServerSessionImpl::send, TransactionImpl and in depage logic. This should be put in one place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191154#4191154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191154

17 years, 4 months

1
0
0 / 0

[Design of Embedded JBoss] - Re: New Embedded Prototype

by alesj

Along with adding some more memory, it's probably useful to set these two vfs config options: -Djboss.vfs.cache=org.jboss.virtual.plugins.cache.TimedVFSCache -Djboss.vfs.forceCopy=true View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191152#4191152 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191152

17 years, 4 months

1
0
0 / 0

[Design of Embedded JBoss] - Re: New Embedded Prototype

by scott.stark＠jboss.org

I downloaded it and ran the package target and the test is failing with an OutOfMemoryError on some vfs copy: | <testcase classname="org.jboss.embedded.test.server.ServerUnitTestCase" time="1.562" name="testServerStart"> | <error type="java.lang.OutOfMemoryError" message="Java heap space">java.lang.OutOfMemoryError: Java heap space | at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:95) | at org.jboss.virtual.VFSUtils.copyStream(VFSUtils.java:773) | at org.jboss.virtual.VFSUtils.copyStreamAndClose(VFSUtils.java:733) | at org.jboss.virtual.plugins.context.zip.ZipEntryContext.findEntry(ZipEntryContext.java:308) | at org.jboss.virtual.plugins.context.zip.ZipEntryContext.createZipSource(ZipEntryContext.java:287) | at org.jboss.virtual.plugins.context.zip.ZipEntryContext.init(ZipEntryContext.java:217) | at org.jboss.virtual.plugins.context.zip.ZipEntryContext.<init>(ZipEntryContext.java:148) | at org.jboss.virtual.plugins.context.zip.ZipEntryContext.<init>(ZipEntryContext.java:133) | at org.jboss.virtual.plugins.context.zip.ZipEntryContextFactory.getVFS(ZipEntryContextFactory.java:71) | at org.jboss.virtual.VFS.getVFS(VFS.java:157) | at org.jboss.virtual.VFS.getRoot(VFS.java:172) | at org.jboss.virtual.spi.cache.helpers.NoopVFSCache.getFile(NoopVFSCache.java:48) | at org.jboss.virtual.VFS.getCachedFile(VFS.java:191) | at org.jboss.bootstrap.BaseServerConfig.getFile(BaseServerConfig.java:740) | at org.jboss.bootstrap.BaseServerConfig.<init>(BaseServerConfig.java:111) | at org.jboss.bootstrap.AbstractServerImpl.doInit(AbstractServerImpl.java:170) | at org.jboss.bootstrap.AbstractServerImpl.init(AbstractServerImpl.java:153) | at org.jboss.embedded.server.JBossEmbeddedAS.<init>(JBossEmbeddedAS.java:123) | at org.jboss.embedded.test.server.ServerUnitTestCase.testServerStart(ServerUnitTestCase.java:39) | ... | </error> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191146#4191146 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191146

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: UnwrapValueUnitTestCase.testCollectionUnwrap failure on

by alesj

"adrian(a)jboss.org" wrote : | I assume you're using a WeakHashMap<ClassInfo, Map> | not a WeakValueHashMap as originally proposed? | This was already originally proposed. ;-) "alesj" wrote : | - protected Map<ClassLoader, Map<String, Map<BeanAccessMode, BeanInfo>>> cache = new WeakHashMap<ClassLoader, Map<String, Map<BeanAccessMode, BeanInfo>>>(); | + protected Map<ClassInfo, Map<BeanAccessMode, BeanInfo>> cache = new WeakHashMap<ClassInfo, Map<BeanAccessMode, BeanInfo>>(); | But it was more by luck then intention. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191144#4191144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191144

17 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008