May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-747) org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer

by Ron Sigal (JIRA)

org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer ---------------------------------------------------------------------------------------- Key: JBREM-747 URL: http://jira.jboss.com/jira/browse/JBREM-747 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one). The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253) at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799) The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered. The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker. As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory instead. -- 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

18 years, 11 months

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-743) For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler

by Ron Sigal (JIRA)

For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler -------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-743 URL: http://jira.jboss.com/jira/browse/JBREM-743 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. The semantics, according to Chapter 5 of the Remoting guide, should be If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect. So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair. -- 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

18 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-641) re-implement the callback polling for http transport to reduce latency

by Tom Elrod (JIRA)

re-implement the callback polling for http transport to reduce latency ---------------------------------------------------------------------- Key: JBREM-641 URL: http://jira.jboss.com/jira/browse/JBREM-641 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: callbacks Affects Versions: 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period. -- 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

18 years, 11 months

2
12
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1285) portal testsuite report generation issue with ant that ships with portal

by Prabhat Jha (JIRA)

portal testsuite report generation issue with ant that ships with portal ------------------------------------------------------------------------ Key: JBPORTAL-1285 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1285 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.Alpha2 Reporter: Prabhat Jha When running portal testsuite with ANT_HOME set to jboss-portal-2.6/tools, report generation is failing "Could not find a valid processor version implementation from com.icl.saxon.TransformerFactoryImpl" It could be related to incompatible saxon.jar with jdk or somehow jar not getting included in classpath. This needs to be fixed. See: http://jboss.org/index.html?module=bb&op=viewtopic&p=4019427#4019427 -- 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

18 years, 11 months

3
11
0 / 0

[JBoss JIRA] Created: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored

by Galder Zamarreno (JIRA)

CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored ------------------------------------------------------------------------------------------ Key: JGRP-507 URL: http://jira.jboss.com/jira/browse/JGRP-507 Project: JGroups Issue Type: Bug Reporter: Galder Zamarreno Assigned To: Bela Ban Fix For: 2.3 SP1, 2.3 A race condition in JGroups could cause a channel that should be closed (for example, after being shunned) to never be closed. In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread status as interrupted. If the interruption occurs while TimeScheduler is waiting, then no problems. But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside synchronized(queue) block which means that CloserThread could set the TimeSchedule thread's status as interrupted while the task is running, for example, sending an FD are-you-alive message. If down the protocol that's carrying out the task, all down threads are set to false, and TimeScheduler thread is interrupted while the task is running, the interruption could be caught while sending a message to network: TP (UDP and TCP/TCP_NIO's parent): TP.down(Event evt) .... try { if(use_outgoing_packet_handler) outgoing_queue.put(msg); else send(msg, dest, multicast); } catch(QueueClosedException closed_ex) { } catch(InterruptedException interruptedEx) { } catch(Throwable e) { if(log.isErrorEnabled()) log.error("failed sending message", e); } Catching InterruptedException and doing nothing will clear the Thread's interrupted status. If the interruption from CloserThread is caught here, TimeScheduler thread will never finished, leaving the channel blocked and never rejoining the cluster. -- 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

18 years, 11 months

2
9
0 / 0

[JBoss JIRA] Created: (JBAOP-387) Throw Exceptions when an valid advice is not found

by Flavia Rainone (JIRA)

Throw Exceptions when an valid advice is not found -------------------------------------------------- Key: JBAOP-387 URL: http://jira.jboss.com/jira/browse/JBAOP-387 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Flavia Rainone Assigned To: Flavia Rainone Fix For: 2.0.0.alpha5 We need to throw an exception warning the user that a valid advice method couldn't be found for a specific joinpoint scenario. (currently, we are printing warnings in the org.jboss.aop.advice.annotation.AdviceMethodFactory algorithm). This task involves changes to org.jboss.aop.advice.PerVMAdvice and org.jboss.aop.advice.annotation.AdviceMethodFactory classes. -- 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

18 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JBFORUMS-229) Redesign LnF for Moderator Panel

by James Cobb (JIRA)

Redesign LnF for Moderator Panel -------------------------------- Key: JBFORUMS-229 URL: http://jira.jboss.com/jira/browse/JBFORUMS-229 Project: JBoss Forums Issue Type: Task Reporter: James Cobb Assigned To: James Cobb Redesign the page view based on the new forums look and feel. Look for usability wins in the process. Whole moderator panel is not rethemed. You need to log in as admin/admin: http://forums.proto.jboss.com:8080/portal/auth/portal/default/Forum/Forum... -- 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

18 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (JBFORUMS-235) Redesign LnF for SplitTopicView

by Ryszard Kozmik (JIRA)

Redesign LnF for SplitTopicView -------------------------------- Key: JBFORUMS-235 URL: http://jira.jboss.com/jira/browse/JBFORUMS-235 Project: JBoss Forums Issue Type: Task Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Meriah Garrett Fix For: 1.0.1 RC Redesign the page view based on the new forums look and feel. Look for usability wins in the process. SplitTopicView available here : http://forums.proto.jboss.com:8080/portal/auth/portal/default/Forum/Forum... -- 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

18 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-975) HA-JNDI InitialContext for @Resource annotation

by Ana Holzbach (JIRA)

HA-JNDI InitialContext for @Resource annotation ----------------------------------------------- Key: EJBTHREE-975 URL: http://jira.jboss.com/jira/browse/EJBTHREE-975 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.0 GA Reporter: Ana Holzbach We're deploying ejbs in a clustered environment that access JMS topics with @Resource annotation as follows: @Resource(mappedName = "TopicConnectionFactory") private ConnectionFactory mJmsConnectionFactory; @Resource(mappedName = "topic/RoomService/BedStaffUpdate") private Topic mStaffUpdateTopic; The topics are deployed in deploy-hasingleton and are available to the singleton master in the cluster only. The remaining nodes get the following error: javax.naming.NameNotFoundException: topic not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:529) at org.jnp.server.NamingServer.getBinding(NamingServer.java:537) at org.jnp.server.NamingServer.getObject(NamingServer.java:543) at org.jnp.server.NamingServer.lookup(NamingServer.java:267) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) at javax.naming.InitialContext.lookup(InitialContext.java:351) at flex.messaging.services.messaging.adapters.JMSProxy.getDestination(JMSProxy.java:186) at flex.messaging.services.messaging.adapters.JMSTopicConsumer.start(JMSTopicConsumer.java:59) at flex.messaging.services.messaging.adapters.JMSAdapter.manage(JMSAdapter.java:345) at flex.messaging.services.MessageService.manageSubscriptions(MessageService.java:571) at flex.messaging.services.MessageService.serviceCommand(MessageService.java:152) at flex.messaging.MessageBroker.routeCommandToService(MessageBroker.java:622) at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:298) at flex.messaging.endpoints.rtmp.AbstractRTMPServer.dispatchMessage(AbstractRTMPServer.java:682) at flex.messaging.endpoints.rtmp.NIORTMPConnection$RTMPReader.run(NIORTMPConnection.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut or.java:643) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j ava:668) at java.lang.Thread.run(Thread.java:595) See also http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049784#4049784 According to Brian Stansberry the @Resource annotations are resolved relative to a default initial context, which will not work for the clustered environment, since we need access to the HA-JNDI context for these. Also according to Brian, getJndiProperties() in DeploymentUnit should be responsible for reading jndi properties defined at deployment through which we might be able to define an HA-JNDI context, but this method returns null in jboss 4.x and also in "2 out of the 3 impls in the AS 5 codebase". See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109219 -- 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

18 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-849) DynamicRulesTest fails with JDK 1.6

by Lars Ivar Igesund (JIRA)

DynamicRulesTest fails with JDK 1.6 ----------------------------------- Key: JBRULES-849 URL: http://jira.jboss.com/jira/browse/JBRULES-849 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR2 Environment: Linux, JDK 1.6 Reporter: Lars Ivar Igesund Assigned To: Mark Proctor I'm doing mvn install from trunk, using JDK 1.6 on Kubuntu Linux. For module drools-compiler, testDynamicFunction in the file below results in an ERROR drools-compiler/src/test/java/org/drools/integrationtests/DynamicRulesTest.java The contents of drools-compiler/target/surefire-reports/org.drools.integrationtests.DynamicRulesTest.txt are ------------------------------------------------------------------------------ Test set: org.drools.integrationtests.DynamicRulesTest ------------------------------------------------------------------------------- Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.008 sec <<< FAILURE! testDynamicFunction(org.drools.integrationtests.DynamicRulesTest) Time elapsed: 0.036 sec <<< ERROR! java.lang.NoClassDefFoundError: org/drools/test/AddFive at org.drools.test.Rule_global_rule_test_0.consequence(Rule_global_rule_test_0.java:9) at org.drools.test.Rule_global_rule_test_0ConsequenceInvoker.evaluate(Rule_global_rule_test_0ConsequenceInvoker.java:20) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:497) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:461) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:372) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:353) at org.drools.integrationtests.DynamicRulesTest.testDynamicFunction(DynamicRulesTest.java:312) at org.drools.integrationtests.DynamicRulesTest.testDynamicFunction(DynamicRulesTest.java:312) 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:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) -- 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

18 years, 11 months

3
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2007