[JBoss JIRA] Created: (JBAS-7875) Auto creation of destinations for MDBs is broken
by jaikiran pai (JIRA)
Auto creation of destinations for MDBs is broken
------------------------------------------------
Key: JBAS-7875
URL: https://jira.jboss.org/jira/browse/JBAS-7875
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3, JMS (HornetQ)
Reporter: jaikiran pai
Assignee: Carlo de Wolf
Fix For: JBossAS-6.0.0.M3
The auto creation of destinations for MDBs is broken in AS trunk with HornetQ. The org.jboss.as.integration.hornetq.deployers.DestinationFactoryDeployerPlugin responsible for creating the destination has multiple issues:
1) It uses the "destination" activation config property as the destination *name* and then creates a jndi name for that destination. This is incorrect because the "destination" activation config property itself is the jndi name.
2) This org.jboss.as.integration.hornetq.deployers.DestinationFactoryDeployerPlugin along with the CreateDestinationDeployer creates a JMSConfiguration as an attachment to the deployment unit. If there are more than one MDBs which require creation of destinations, then this deployer ends up using the same attachment name for both the attachment names, ending up the "last one is the winner" scenario.
--
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
16 years, 3 months
[JBoss JIRA] Created: (JBAS-7827) Create a JSR-160 connector server deployment in AS
by David Lloyd (JIRA)
Create a JSR-160 connector server deployment in AS
--------------------------------------------------
Key: JBAS-7827
URL: https://jira.jboss.org/jira/browse/JBAS-7827
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: JMX
Reporter: David Lloyd
Assignee: Scott Marlow
Fix For: JBossAS-6.0.0.M3
<dmlloyd> don't do it this way :)
<dmlloyd> instead, implement it as a service
<dmlloyd> write a jboss-beans.xml which creates a...
<dmlloyd> ~~ smarlow javadoc RMIServerImpl
<javabot> smarlow: http://is.gd/aPe3U [JDK: javax.management.remote.rmi.RMIServerImpl]
<dmlloyd> and injects the MBeanServer from the MC
<dmlloyd> then for now just stick it into deploy/ (we can move it to an earlier bootstrap phase at a later time)
<Nihility> ~ javadoc RMIConnectorServer
<javabot> http://is.gd/4roR1 [JDK: javax.management.remote.rmi.RMIConnectorServer]
<dmlloyd> ah yeah
<smarlow> sure, that sounds better
<dmlloyd> taht's the better choice :)
<Nihility> we needed to do that anyway
<Nihility> this will make it easy to configure
<Nihility> which i like
<Nihility> also it lets us secure the connection
<dmlloyd> smarlow, so for now just a jboss-beans.xml will do it. Sometime later (M4) we can make a special domain-esque <jmx-connector-server .../> thing
<smarlow> dmlloyd: sounds great, thanks!
--
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
16 years, 3 months
[JBoss JIRA] Created: (JGRP-1090) Many retransmissions with message bundling and OOB messages
by Bela Ban (JIRA)
Many retransmissions with message bundling and OOB messages
-----------------------------------------------------------
Key: JGRP-1090
URL: https://jira.jboss.org/jira/browse/JGRP-1090
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
When message bundling is enabled, we queue *regular* messages until max_bundle_size has been reached or max_bundle_timeout has exceeded.
The problem is that - when sending OOB (as opposed to regular) messages - they're *not* queued. This means the OOB message is possibly received *before* the regular messages and thus causes retransmission !
E.g. we send regular message 1-10, then OOB message 11.
Say 1-3 are sent immediately (because the bundle timeout kicked in or the size was exceeded). Messages 4-10 are queued and sent later. Message 11 is sent immediately.
On the receiver side, message reception could be for example: 1-3, 11, 4-10
When OOB message 11 is received, the receiver asks for retransmission of messages 4-10 !
This is not incorrect, but causes a lot of unneeded retransmissions !
public static void main(String[] args) throws Exception {
JChannel c1=new JChannel("/home/bela/fast.xml");
c1.connect("bla3");
JChannel c2=new JChannel("/home/bela/fast.xml");
c2.connect("bla3");
for(int i=1; i <= 20; i++) {
c1.send(null, null, "hello-" + i);
}
Message oob_msg=new Message(null, null, "oob msg");
oob_msg.setFlag(Message.OOB);
c1.send(oob_msg);
Util.sleep(20000);
Util.close(c2, c1);
}
--
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
16 years, 3 months