Delivery Notification <antonette.bell@umcsn.com>
by Postmaster@lists.jboss.org
This is a delivery status notification, automatically generated by MTA umcsecmx1.umcsn.com on Thu, 24 Apr 2008 07:30:48 -0700
Regarding recipient(s) : antonette.bell(a)umcsn.com
Delivery status : Failed. Message could not be delivered to domain <umcsn.com> .Error while sending data.
MTA Response :550
The original message headers are included as attachment.
16 years, 6 months
[Design of EJB 3.0] - Re: JBMETA-6, JBMETA-25 resolved jndi name
by scott.stark@jboss.org
The DefaultJndiBindingPolicy does not accept the metadata. Rather it takes a summary of the ejb deployment/bean in question:
| public interface DefaultJndiBindingPolicy
| {
| /**
| * Returns the JNDI name that should be assigned to this deployment
| * based on the information contained in the specified summary
| *
| * @param summary
| * @return
| */
| String getJndiName(EjbDeploymentSummary summary);
|
| String getDefaultRemoteJndiName(EjbDeploymentSummary summary);
|
| String getDefaultRemoteHomeJndiName(EjbDeploymentSummary summary);
|
| String getDefaultLocalHomeJndiName(EjbDeploymentSummary summary);
|
| String getDefaultLocalJndiName(EjbDeploymentSummary summary);
| }
| public class EjbDeploymentSummary
| {
| // Instance Members
| private String deploymentName;
| private String deploymentScopeBaseName;
| private String ejbName;
| private String beanClassName;
| private boolean isLocal;
| private boolean isStateful;
| private boolean isHome;
| private boolean isService;
| private ClassLoader loader;
| ...
| // accessors omitted
| }
|
The determineJndiName(EjbDeploymentSummary) on the base class just implements the default name based on the DefaultJndiBindingPolicy. The entity and session bean metadata still have the determineJndiName() which has the old logic as well as an overriden determineJndiName(EjbDeploymentSummary) which looks at the other sources of jndi names before defaulting to the superclass policy version.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146525#4146525
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146525
16 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Resource GC problem
by harish43
Tim,
Do you know which version of JBoss Messaging contains the fix you mention?
Also is there a corresponding fix in JBoss Remoting as well? If so in which version is it?
We are experiencing similar issues when load testing with JBoss Messaging with usage pattern of JMS connections being very similar (lookup factory, lookup queue, connect to queue, open session, send message, close connection) but we are using a JMS connection max-pool-size of 20 as defined in the tx-connection-factory in jms-ds.xml.
Our environment is :
JBM 1.4.0 SP3
JBoss AS 4.2.2 GA
JDK 1.5.0_06
Redhat Linux
MySQL for JMS persistence
Sybase for data persistence
As mentioned by Kevin Conner the BisocketServerInvoker$ControlMonitorTimerTask and BisocketClientInvoker and HashMaps are growing in number and size throughout the test and never getting GC'd.
Any help is appreciated.
Harish.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146523#4146523
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146523
16 years, 6 months