[JBoss JIRA] Created: (JBAS-5019) Turn ClusterNode into an interface
by Brian Stansberry (JIRA)
Turn ClusterNode into an interface
----------------------------------
Key: JBAS-5019
URL: http://jira.jboss.com/jira/browse/JBAS-5019
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
Fix For: JBossAS-5.0.0.Beta3
ClusterNode leaks the JGroup IpAddress class via getOriginalJGAddress. AFAICT the only code that uses that method is ClusterPartition. So, look into making ClusterNode an interface that doesn't expose getOriginalJGAddress(). ClusterPartition can use the method on the implementing class, which it controls.
--
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
[JBoss JIRA] Created: (JBREM-746) need to be able to tell ServerInvokerServlet to use the platform MBean server
by John Mazzitelli (JIRA)
need to be able to tell ServerInvokerServlet to use the platform MBean server
-----------------------------------------------------------------------------
Key: JBREM-746
URL: http://jira.jboss.com/jira/browse/JBREM-746
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.SP4
Reporter: John Mazzitelli
Assigned To: Ron Sigal
Right now, ServerInvokerServlet assumes the MBeanServer where it can find the server invoker is the JBoss MBeanServer.
See the comments in ServerInvokerServlet.getMBeanServer()
It would be nice to be able to tell it to not use the MBeanServer whose default domain is "jboss", but rather we should be able to tell it (via servlet init params) either:
a) the name of the MBeanServer's default domain (in case I want to use my own, not the jboss one)
or
b) a flag to indicate it should use the Java5 platform MBeanServer (java.lang.management.ManagementFactory.getPlatformMBeanServer())
Workaround is for customers to write their own subclass of ServerInvokerServlet, override the getMBeanServer method to find the appropriate one.
--
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, 1 month
[JBoss JIRA] Created: (JBMESSAGING-1171) Session.close (indirectly Producer.close) should wait async execution buffers to be emptied before closing channels
by Clebert Suconic (JIRA)
Session.close (indirectly Producer.close) should wait async execution buffers to be emptied before closing channels
-------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1171
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1171
Project: JBoss Messaging
Issue Type: Bug
Reporter: Clebert Suconic
Assigned To: Tim Fox
Fix For: 1.4.0.SP2
To easily replicate this, use org.jboss.test.messaging.jms.stress.SeveralClientsStressTest
At your workspace you could lower the total time for the execution. (I will have attached a patch on this JIRA)
protected static long PRODUCER_ALIVE_FOR=5000; // originalValue=60000
protected static long CONSUMER_ALIVE_FOR=5000; // originalValue=60000
protected static long TEST_ALIVE_FOR=15000; // originalValue = 5 * 60 * 1000
protected static int NUMBER_OF_PRODUCERS=50;
protected static int NUMBER_OF_CONSUMERS=50;
The test is loosing messages on this following condition:
- you have N Threads, each Thread equals one Producer, sending messages at a constant rate.
- Each message is sent asynchronously
- After some time the Thread decides to stop producing messages, and immediately closes the session.
- Any message that hasn't been sent to the server yet would be lost.
How to validate what I'm talking about:
Run the testcase as is (lowering the time as I said before on this message).
You will see a warning at the end of the test with non processed messages:
@main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#31", msgToString=[delegator->JBossMessage[463]:NON-PERSISTENT, deliveryId=0]
@main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#29", msgToString=[delegator->JBossMessage[434]:NON-PERSISTENT, deliveryId=0]
@main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#24", msgToString=[delegator->JBossMessage[339]:NON-PERSISTENT, deliveryId=0]
@main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#26", msgToString=[delegator->JBossMessage[374]:NON-PERSISTENT, deliveryId=0]
If you look on logs you will realize that any message appearing on this list didn't make to the server. and it will aways coincide with the very few last messages sent on this thread.
If you put a Thread.sleep(10000); before the conn.close() on SeveralClientsStressTest.Producer (line 422) the test will pass:
Thread.sleep(10000);
finally
{
Thread.sleep(10000);
conn.close();
}
- Somehow producer.close / session.close should empty the async buffer before closing the session.
I have attached a patch for this test.
--
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, 1 month