May 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on ReplicationAwareJMSServerControlWrapperTest

by clebert.suconic＠jboss.com

I created a jira for ReplicationAwareJMSServerControlWrapperTest: https://jira.jboss.org/jira/browse/JBMESSAGING-1618 and I added a fixme on the test. The test is now passing considering that connection.close() could be asynchronous, however it needs to be fixed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228799#4228799 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228799

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on ReplicationAwareJMSServerControlWrapperTest

by clebert.suconic＠jboss.com

"timfox" wrote : Let me clarify this: | | *We need to get the test suite run green* | | That means, in case it's not clear | | *No working on other tasks until that is done* | | Hope that is clear now. | | Thanks. Did anyone say anything different than that? You were pointing out tests that are not failing for me or Hudson. I just wanted to clarify on those. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228793#4228793 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228793

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: OnDemand as an aspect

by jason.greene＠jboss.com

"david.lloyd(a)jboss.com" wrote : Perhaps a more sane solution is to have a lazy servlet initialization function in JBossWeb. I don't think this is a "healthy" general-purpose solution, because the patterns it encourages are almost never desirable. For example, you only describe using it as a workaround for another problem. The use case is development, and you are only working with 1 of the 300 apps you have "deployed". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228792#4228792 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228792

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on ReplicationAwareJMSServerControlWrapperTest

by timfox

Let me clarify this: *We need to get the test suite run green* That means, in case it's not clear *No working on other tasks until that is done* Hope that is clear now. Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228791#4228791 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228791

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on ReplicationAwareJMSServerControlWrapperTest

by clebert.suconic＠jboss.com

"timfox" wrote : I just ran a test suite, I got failures on: | 1. ReplicationAwareJMSServerControlWrapperTest | This is what I said on the first post anonymous wrote : | 3. org.jboss.messaging.tests.integration.jms.server.management.JMSQueueControlUsingJMSTest | 4. org.jboss.messaging.tests.integration.jms.server.management.JMSServerControl2Test | | I don't see these failures.. I already ran these two for about 20 times, also testListClientConnectionsForNetty in a loop of 100. and didn't see any failure. Didn't see those failures on latest hudson also. This was the last Jeff's commit today. Maybe there is some sync issue at your workspace. I will be looking at (2) JMSServerDeployerTest, allthough I'm not sure why you listed it as a management test. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228790#4228790 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228790

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: REST integration within JBoss ESB

by burrsutter

How about: - basic-auth - https - XSD validation of the inbound request body, outbound response body - CBR based on partial or whole URIs - where the routed-to service can provide the response I think the biggest trick is how all the HTTP headers, request content, and response body are mapped to the ESB message and made available in actions. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228787#4228787 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228787

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - All sorts of failures with JDK 1.6

by clebert.suconic＠jboss.com

If you use JDK 1.6 on the testsuite, you will get all sort of failures... with *lots* of failures. A good example would be: org.jboss.messaging.tests.integration.cluster.distribution.NettyFileStorageSymmetricClusterTest::testRoundRobinMultipleQueues | MessagingException[errorCode=2 message=Unable to connect to server using configuration org-jboss-messaging-integration-transports-netty-NettyConnectorFactory?jbm-remoting-netty-port=5447&jbm-remoting-invm-serverid=2] | at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.createSession(ConnectionManagerImpl.java:278) | at org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:915) | at org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:715) | at org.jboss.messaging.tests.integration.cluster.distribution.ClusterTestBase.addConsumer(ClusterTestBase.java:287) | at org.jboss.messaging.tests.integration.cluster.distribution.SymmetricClusterTest.testRoundRobinMultipleQueues(SymmetricClusterTest.java:238) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:597) | at junit.framework.TestCase.runTest(TestCase.java:164) | at junit.framework.TestCase.runBare(TestCase.java:130) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:120) | at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) | at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) | 17:12:50,391 WARN @New I/O server boss #5 (channelId: 660493198, /127.0.0.1:5449) [NioServerSocketPipelineSink] Failed to initialize an accepted socket. | org.jboss.netty.channel.ChannelException: Failed to create a selector. | at org.jboss.netty.channel.socket.nio.NioWorker.register(NioWorker.java:102) | at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink$Boss.run(NioServerSocketPipelineSink.java:210) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) | at java.lang.Thread.run(Thread.java:619) | Caused by: java.io.IOException: Too many open files | at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method) | at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:68) | at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:52) | at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) | at java.nio.channels.Selector.open(Selector.java:209) | at org.jboss.netty.channel.socket.nio.NioWorker.register(NioWorker.java:100) | ... 4 more | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228784#4228784 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228784

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on ReplicationAwareJMSServerControlWrapperTest

by timfox

I just ran a test suite, I got failures on: 1. ReplicationAwareJMSServerControlWrapperTest 2. org.jboss.messaging.tests.integration.jms.server.JMSServerDeployerTest 3. org.jboss.messaging.tests.integration.jms.server.management.JMSQueueControlUsingJMSTest 4. org.jboss.messaging.tests.integration.jms.server.management.JMSServerControl2Test This don't seem intermittent and I am up to date with svn. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228782#4228782 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228782

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Failure on ReplicationAwareJMSServerControlWrapperTest

by clebert.suconic＠jboss.com

The only failure we have on management now is ReplicationAwareJMSServerControlWrapperTest::testListRemoteAddresses which is due to the issues we have with connections. A call to connection.close() leads to the ServerConnection being close Asynchronously.. so there is nothing wrong with management on that test, as a call to session.close() should make the close on server Synchronously and not Asynchronously as it's happening now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228781#4228781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228781

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: OnDemand as an aspect

by jason.greene＠jboss.com

"david.lloyd(a)jboss.com" wrote : | To me it makes more sense to restrict our usage of on-demand beans to deployments that are only activated if a user deployment consumes it declaratively (in other words, beans depend on beans; methods do not depend on beans). | | Also, and I only speak for myself here, I'm personally really hesitant to invest more into AOP, given that AOP appears to be at least one key source of the performance problems that we have right now. To do on-demand properly, we do need a first request activation mechanism. However, it seems like using an activation aspect is overkill. Why can't the API just be simplified, or better yet automated on first non-lifecycle MC method access. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228780#4228780 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228780

16 years, 11 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 May 2009