August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBREM-218) investigate why jrunit report on cruisecontrol inaccurate

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-218?page=comments#action_12340464 ] Tom Elrod commented on JBREM-218: ---------------------------------- Still some random failures within cruisecontrol. At this point, these are all linked to problems with jrunit and all pass when run via an ide. > investigate why jrunit report on cruisecontrol inaccurate > --------------------------------------------------------- > > Key: JBREM-218 > URL: http://jira.jboss.com/jira/browse/JBREM-218 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.4.0 beta > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.0.0.CR1 (Boon) > > > http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.5/... (and several previous ones) shows that the socket transport tests are extremely slow. This should not be the case (local performance tests using same ant build target as cruisecontrol consistenly shows is the fastest). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-534) multiplex client cannot re-connect to server after it has died and then been re-started

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-534?page=all ] Ron Sigal closed JBREM-534. --------------------------- Resolution: Done The code changes have already been described in a previous comment. The unit test introduced for this issue had some failures because the client invoker was getting a stale thread from the connection pool, in the case that connection checking is turned off. It seems reasonable, however, that if the user turns off connection checking, then the application code should be responsible for handling this problem. The unit test was changed to make to attempts to call Client.invoke(), so that if the first attempt failed due to a stale thread, the second call will lead to the creation of a new connection to a new Connector. > multiplex client cannot re-connect to server after it has died and then been re-started > --------------------------------------------------------------------------------------- > > Key: JBREM-534 > URL: http://jira.jboss.com/jira/browse/JBREM-534 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport-multiplex > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Tom Elrod > Assigned To: Ron Sigal > Fix For: 2.0.0.CR1 (Boon) > > > "However, I have found another issue that still needs looking into. If using multiplex transport and a server is killed and then re-started, it looks like the detector sees the server restarting, then tries to ping it, but can not, so discards it as being dead, then repeats this process. This does not happen when using socket transport, so looks like there is some issue where multiplex client is having trouble making invocations on a server after it has gone down and then come back up." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-551) org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization) failure

by Ron Sigal (JIRA)

org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization) failure ------------------------------------------------------------------------------------------------ Key: JBREM-551 URL: http://jira.jboss.com/jira/browse/JBREM-551 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 (Boon) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.0.0.CR1 (Boon) There seem to be two sources of exceptions here: 1. When a Connector shuts down and a MultiplexingManager is still running on remote end (not sure how this happened), the remote OutputMultiplexor will get "Broken pipe" exceptions. 2. When a Connector shuts down, the master MultiplexServerInvoker can shut down a virtual MultiplexServerInvoker, interruptting an acceptThread, which cause the VirtualServerSocket to think it has reached end of file. Not sure how these problems caused the test to fail, however. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
2
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-319) Enable the Messaging build to use component-info.xml and versioned dependencies

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-319?page=all ] Ovidiu Feodorov closed JBMESSAGING-319. --------------------------------------- Resolution: Done > Enable the Messaging build to use component-info.xml and versioned dependencies > ------------------------------------------------------------------------------- > > Key: JBMESSAGING-319 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-319 > Project: JBoss Messaging > Issue Type: Task > Components: Build System > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: 1.2.0.Alpha1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-563) Multiplex ClientConfigurationCallbackConnectorTestCase(jboss_serialization) failure

by Ron Sigal (JIRA)

Multiplex ClientConfigurationCallbackConnectorTestCase(jboss_serialization) failure ----------------------------------------------------------------------------------- Key: JBREM-563 URL: http://jira.jboss.com/jira/browse/JBREM-563 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 (Boon) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.0.0.CR1 (Boon) The first of five test methods failed because it was unable to connect to a Connector. The subsequent test methods passed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-473) Remote test reports overwrite local test reports

by Ovidiu Feodorov (JIRA)

Remote test reports overwrite local test reports ------------------------------------------------ Key: JBMESSAGING-473 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-473 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Alpha1 When the remote tests run they don't write their reports with the -REMOTE suffix so they overwrite the local tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBRULES-328) FactTemplates

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-328?page=all ] Mark Proctor updated JBRULES-328: --------------------------------- Summary: FactTemplates (was: Implement Template support for "soft" Columns) > FactTemplates > ------------- > > Key: JBRULES-328 > URL: http://jira.jboss.com/jira/browse/JBRULES-328 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assigned To: Mark Proctor > Fix For: 3.1-m1 > > > We should allow clips style templates for Columns -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-673) Cannot change default InvokerLocator port for EJB3 Deployer

by Andrew Rubinger (JIRA)

Cannot change default InvokerLocator port for EJB3 Deployer ----------------------------------------------------------- Key: EJBTHREE-673 URL: http://jira.jboss.com/jira/browse/EJBTHREE-673 Project: EJB 3.0 Issue Type: Bug Environment: JBoss 4.0.4-GA w/ EJB3 Profile as installed by JNLP Installer. Properties Service Plugin and Binding Service Plugin added manually after initial install (as they were not included in the EJB3 profile). Windows XP Professional, Service Pack 2. Reporter: Andrew Rubinger Default InvokerLocator port for EJB3 cannot be changed/found correctly when using JBoss Binding Service Plugin. Use Case: Given two server instances, A and B. The binding service plugin is being used with all defaults from "sample-bindings.xml" as obtained from $JBOSS_HOME/docs/examples/binding-manager. Server Instance A is configured to use ServerName "ports-default" in the bindings. Server Instance B is configured to use ServerName "ports-01" in the bindings. Instances deploy on the same machine simultaneously. With both instances running, EJB3 archive is deployed into Server Instance B. Remote client obtains a stub properly, but once invoking a method on this stub, receives a NotFoundInDispatcherException: java.lang.reflect.UndeclaredThrowableException at $Proxy0.encrypt(Unknown Source) at com.ninem.rx.api.encryption.EncryptionDelegate.encrypt(EncryptionDelegate.java:54) at com.ninem.rx.api.encryption.EncryptionDelegateTests.testRoundtripEncryption(EncryptionDelegateTests.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:228) at junit.framework.TestSuite.run(TestSuite.java:223) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.jboss.aop.NotFoundInDispatcherException: Object with oid: jboss.j2ee:jar=rx_service-encryption.ejb3,name=EncryptionServiceBean,service=EJB3 was not found in the Dispatcher at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:85) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.service.ServiceRemoteProxy.invoke(ServiceRemoteProxy.java:92) ... 18 more Instance A is shut down. Same remote client runs same execution process. EJB3 stub again obtained without error, but upon invoking a method on the stub, receives a org.jboss.remoting.CannotConnectException: org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection. at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:267) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.service.ServiceRemoteProxy.invoke(ServiceRemoteProxy.java:92) at $Proxy0.encrypt(Unknown Source) at com.ninem.rx.api.encryption.EncryptionDelegate.encrypt(EncryptionDelegate.java:54) at com.ninem.rx.api.encryption.EncryptionDelegateTests.testRoundtripEncryption(EncryptionDelegateTests.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:228) at junit.framework.TestSuite.run(TestSuite.java:223) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.<init>(Unknown Source) at java.net.Socket.<init>(Unknown Source) at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:535) at org.jboss.remoting.transport.socket.SocketClientInvoker.getConnection(SocketClientInvoker.java:471) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:263) ... 30 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-3318) Secondary http sessions in a cross-context request are not replicated

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3318?page=all ] Brian Stansberry closed JBAS-3318. ---------------------------------- Resolution: Done > Secondary http sessions in a cross-context request are not replicated > --------------------------------------------------------------------- > > Key: JBAS-3318 > URL: http://jira.jboss.com/jira/browse/JBAS-3318 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Clustering > Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-4.0.5.CR1 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > If cross-context requests are enabled and a servlet accesses the request dispatcher and dispatches the request to a different context, no session replication is performed for the session in that second context. This is because a dispatched request bypasses the ClusteredSessionValve, and thus replication is not triggered. > Likely solution is to have ClusteredSessionValve create some sort of ThreadLocal replication context. Any JBossCacheManager that accesses a session will associate itself and the session with the replication context.. Then when the request returns through the ClusteredSessionValve, all sessions in the context will be replicated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-469) Clarify how build-thirdparty.xml's <build> task attributes should be used.

by Ovidiu Feodorov (JIRA)

Clarify how build-thirdparty.xml's <build> task attributes should be used. -------------------------------------------------------------------------- Key: JBMESSAGING-469 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-469 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.2.0.Alpha1 Investigate if build-thirdparty.xml <build>'s id, impltitle, implversion, implvendor, implurl have the same purpose with similar properties defined in build.xml. Which one should be used? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006