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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Producer hangs after 20M sent

by timfox

"ataylor" wrote : Yeah, it's definitely producer flow control. If you set it to -1 however, you quite quickly get an out of memory exception. I'll raise a JIRA That's to be expected, since you're not limiting flow to the server any more (with -1). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165596#4165596 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165596

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Problem handling absolute directory specs in classpath

by adinn

Hi guys. I've found another small deployer issue to do with class paths in war files. The XTS demo program included a manifest whose classpath referred,inter alia, to /WEB-INF/classes. When this gets deployed it generates the following error display: | at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) | at org.jboss.deployers.structure.spi.helpers.AbstractStructureBuilder.populateContext(AbstractStructureBuilder.java:144) | at org.jboss.deployers.structure.spi.helpers.AbstractStructureBuilder.populateContext(AbstractStructureBuilder.java:83) | at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:89) | at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:845) | at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:303) | at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:260) | at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:267) | at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221) | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) | at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280) | at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.IllegalArgumentException: A path element is empty: xts-demo.ear//WEB-INF/classes | at org.jboss.virtual.plugins.vfs.helpers.PathTokenizer.getTokens(PathTokenizer.java:106) | at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:475) | at org.jboss.virtual.plugins.context.file.FileHandler.getChild(FileHandler.java:233) | at org.jboss.virtual.plugins.context.AbstractVFSContext.getChild(AbstractVFSContext.java:164) | at org.jboss.virtual.VFS.getChild(VFS.java:228) | at org.jboss.virtual.VFSUtils.addManifestLocations(VFSUtils.java:200) | at org.jboss.deployers.vfs.plugins.structure.VFSStructureBuilder.applyContextInfo(VFSStructureBuilder.java:217) | at org.jboss.deployers.structure.spi.helpers.AbstractStructureBuilder.populateContext(AbstractStructureBuilder.java:130) | ... 16 more | After debugging the problem it appears that PathTokenizer.getTokens is being passed a VFS file name of the form | .../xts-demo.ear//WEB-INF/classes | When it conjures up the vfs file name the classpath generator code carefully adds a trailing slash after the .ear file name and then checks for a trailing slash on the manifest class path element. However, it does not check to see if the manifest class path element has a leading slash -- hence the double slash and the claim that a 'path element is empty'. The problem goes away if either i) the manifest entry is changed to WEB-INF.classes or ii) the manifest entry is removed (I know it's redundant but presumably this problem will affect anyone who employs a different absolute path) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165594#4165594 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165594

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Producer hangs after 20M sent

by ataylor

Yeah, it's definitely producer flow control. If you set it to -1 however, you quite quickly get an out of memory exception. I'll raise a JIRA View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165579#4165579 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165579

17 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Repackage of TomcatService

by scott.stark＠jboss.org

The tomcat deployer project should be cleaned up and the old classes dropped as part of the JBAS-5672 cleanup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165558#4165558 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165558

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ManagedObjectAttachmentsImpl::transientManagedObjects no

by scott.stark＠jboss.org

Its transient in that it does not affect that persistent view of the metadata as known by the profile service. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165556#4165556 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165556

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

A question with regards to org.hibernate.test.cache in hibernate-testing module and org.hibernate.test.cache.jbc2.functional package in cache-jbosscache2: cache-jbosscache2 uses hibernate-testing but for some reason, it seems to redefine Item, VersionedItem and Item.hbm.xml. However, after comparing them, they look identical. This is important for me in case I can just use these classes from hibernate-testing module, or you're planning to remove these from here and keep the ones in cache-jbosscache2, in which case I'd need to redefine them for hibernate-jbc-cacheprovider. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165542#4165542 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165542

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

"bstansberry(a)jboss.com" wrote : Re: the tests, there are tests in the Hibernate 3.3 core cache-jboss-cache2 module that avoid using the AS. See the org.hibernate.test.cache.jbc2.functional package. The difficulty is those bring in dependencies on the Hibernate test module, plus I'm sure have JBC 2 ties. So it will require some effort to break those ties and let them run standalone. I've started looking at the dependencies on the test module. Hibernate 3.2.x never produced any binaries with the test classes required to port the org.hibernate.test.cache.jbc2.functional tests. Since 3.3.x though, such jar has been made available (http://repository.jboss.org/maven2/org/hibernate/hibernate-testing/3.3.0....). I've done a diff between the test classes in 3.2.x and trunk and they're almost identical with a few minor differences such as: use of org.slf4j rather than commons logging, and refactoring of DummyConnectionProvider and DummyTransactionManagerLookup into ConnectionProviderImpl and TransactionManagerLookupImpl. There's also a 2 of extra methods in UnitTestCase (createFailureExpectedSuite() method), FunctionalTestCase (isSerializableIsolationEnforced() method) and removed FunctionalTestClassTestSuite(String) constructor from FunctionalTestClassTestSuite. Bottom line: I think I can safely add a dependency for HB 3.3 hibernate testing even though we're testing HB 3.2.x. WDYT? This would much easier than having to now come up with testing jars for 3.2.x series. The downside here is that if we pull 3.3 hibernate testing module, we're indirectly pull other jars but I don't see any direct incompatibilities with what we pull right now for 3.2.x: M2_REPO/junit/junit/3.8.1/junit-3.8.1.jar | M2_REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar | M2_REPO/commons-collections/commons-collections/3.1/commons-collections-3.1.jar | M2_REPO/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar | M2_REPO/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar | M2_REPO/javax/transaction/jta/1.1/jta-1.1.jar | M2_REPO/org/slf4j/slf4j-api/1.4.2/slf4j-api-1.4.2.jar I think it'd be interesting to get Steve's thoughts on this. Thoughts? "bstansberry(a)jboss.com" wrote : On the name, how about "hibernate-jbc-cache-provider"? CacheProvider is the legacy API that's replaced in 3.3. Including it in the name is at least a small indication this is a legacy integration. I like the name, just one little thing. To make the legacy aspect even more obvious, I'd suggest making cache-provider a single word, matching the class CacheProvider class name: i.e. hibernate-jbc-cacheprovider. As an extension of this, I suppose the package name for this classes would be something along: org.jboss.hibernate.jbc.cacheprovider View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165540#4165540 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165540

17 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: [JBWS-2187] javax.xml.ws.Service handlers and thread saf

by darran.lofthouse＠jboss.com

I have my final solution for this issue, I am just running some tests and then I am ready to commit to trunk. The working branch is: - https://svn.jboss.org/repos/jbossws/stack/native/branches/dlofthouse/JBWS... This fix has involved three areas of change. - 1 - The HandlerResolverImpl pased into the ClientImpl is now copied. New collections are created from the contents of the original HandlerResolverImpl. This means both instances may have the same handlers but in their own lists so if either is reconfigured it will not affect the other instance. - 2 - I have removed the Observer/Observable pattern for notification of handler changes. The only place we were using it was to reconfigure the Client hander chains but as said earlier in this discussion changing the configuration on one client should not affect the others. - 3 - Refactored the EndpointMetaData to contain an EndpointConfigMetaData object to encapsulate the configurable values. Generally the use of EndpointMetaData remains the same but if a client needs to it can create a new EndpointConfigMetaData and use that instead so each client can have individual configuration or use the common configuration as required, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165530#4165530 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165530

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Producer hangs after 20M sent

by clebert.suconic＠jboss.com

That's a big coincidence for me... I also ran the same test on friday... I got the stack traces and it had to do with Producer Flow Control. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165516#4165516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165516

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives

by alesj

I've added a fix for this issue - a recursion in case parent classpath is not yet set: | protected static Set<VirtualFile> determineClassPath(DeploymentUnit unit, Module module) | { | ClassPathVisitor visitor = new ClassPathVisitor(unit); | try | { | unit.visit(visitor); | } | catch (DeploymentException e) | { | throw new RuntimeException("Error visiting deployment: " + e); | } | Set<VirtualFile> classPath = visitor.getClassPath(); | // Weed out parent classpaths | if (module != null && module.getParentDomainName() == null) | { | DeploymentUnit parent = unit.getParent(); | while (parent != null) | { | Set<VirtualFile> parentClassPath = parent.getAttachment(VFS_CLASS_PATH, Set.class); | if (parentClassPath == null) | parentClassPath = determineClassPath(parent, parent.getAttachment(Module.class)); | | if (parentClassPath != null && parentClassPath.isEmpty() == false) | { | if (log.isTraceEnabled()) | { | for (VirtualFile parentFile : parentClassPath) | { | if (classPath.contains(parentFile)) | log.trace(unit + " weeding duplicate entry " + parentFile + " from classpath already in parent " + parent); | } | } | classPath.removeAll(parentClassPath); | } | parent = parent.getParent(); | } | } | unit.addAttachment(VFS_CLASS_PATH, classPath); | return classPath; | } | But I'll let you close the JIRA issue if you feel this is a proper fix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165510#4165510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165510

17 years, 8 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 July 2008