[JBoss JIRA] Created: (JGRP-685) Perf test
by Bela Ban (JIRA)
Perf test
---------
Key: JGRP-685
URL: http://jira.jboss.com/jira/browse/JGRP-685
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7
Things to do with the perf test:
- Mimick buddy replication: send messages not to self, but only to a selected buddy
- Measure time to send 100MB to A, B, C, D
- New look at HTOTAL, might help with perf in this scenario
- TcpTransport (95MB/sec) versus JGroupsTransport/tcp.xml (54MB/sec): why the diff ?
- Members: A (send), B (receive)
- Might get better perf with impl of first bullet item (above)
- JPerf (between A and B) gets 113MB/sec !
--
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
13 years, 9 months
[JBoss JIRA] Created: (EJBTHREE-1454) Encapsulate Container infomation in TO/VO
by Andrew Lee Rubinger (JIRA)
Encapsulate Container infomation in TO/VO
-----------------------------------------
Key: EJBTHREE-1454
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1454
Project: EJB 3.0
Issue Type: Task
Components: proxy
Reporter: Andrew Lee Rubinger
Assignee: Andrew Lee Rubinger
Take for instance:
public StatefulSessionProxyFactoryBase(final String name, final String containerName, final String containerGuid,
final JBossSessionBeanMetaData metadata, final ClassLoader classloader, final Advisor advisor)
Where containerName, containerGuid, metadata, CL, and Advisor are all properties of the target container.
This makes for a cluttered API, and affects constructors of Proxy Factories, Handlers, and the JNDI Registrars. Clean it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (JBAS-3630) JMSTransportSupport is not portable across different JMS providers.
by Darran Lofthouse (JIRA)
JMSTransportSupport is not portable across different JMS providers.
-------------------------------------------------------------------
Key: JBAS-3630
URL: http://jira.jboss.com/jira/browse/JBAS-3630
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.4.GA
Reporter: Darran Lofthouse
Assigned To: Thomas Diesler
Fix For: JBossAS-4.0.6.CR1
JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
String fromName = null;
Destination destination = message.getJMSDestination();
if (destination instanceof Queue)
fromName = "queue/" + ((Queue)destination).getQueueName();
if (destination instanceof Topic)
fromName = "topic/" + ((Topic)destination).getTopicName();
For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.
--
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
13 years, 9 months
[JBoss JIRA] Created: (JBAS-5745) ServerMBean.InShutdown flag won't turn on when the shutdown hook is called directly
by Takayoshi Kimura (JIRA)
ServerMBean.InShutdown flag won't turn on when the shutdown hook is called directly
-----------------------------------------------------------------------------------
Key: JBAS-5745
URL: http://jira.jboss.com/jira/browse/JBAS-5745
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: System service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Takayoshi Kimura
Assigned To: Dimitris Andreadis
The ServerMBean.InShutdown flag is only turned on when the shutdown() operation is called. There is another shutdown path, a shutdown hook called by signals including Ctrl+c. This flag is needed to update in the shutdownHook.shutdown() method to reflect the sever status.
--
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
13 years, 10 months
[JBoss JIRA] Created: (JBAS-5554) Cross-cluster dependencies
by Brian Stansberry (JIRA)
Cross-cluster dependencies
--------------------------
Key: JBAS-5554
URL: http://jira.jboss.com/jira/browse/JBAS-5554
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Clustering, Deployers
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Service B on node 2 depends on Service A on node 1.
Per Scott, "Dependencies on components that are marked as @Clustered needs a cluster aware dependency implementation. Custom dependencies are supported by the mc, but the component deployers generating the component metadata have to generate the correct dependency implementation."
This also ties in with the coordinated deployment issue in JBAS-5553, as we wouldn't want Service B deployment to fail on node 2 just because it happened to deploy before Service A on node 1.
--
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
13 years, 10 months