date:20011023


  User: schaefera
  Date: 01/10/23 00:10:45

  Modified:src/main/org/jboss/system FarmMemberService.java
FarmMemberServiceMBean.java
  Log:
  Now the farm does not rely how the members are added it should work any-
  way. The problem was that when a new member is added that the new member
  does not get notified about the existing members which is fixed now.
  Also the deployed services are not pulled from the receiving members
  instead of pushed from the deploying server. Thus if a connection is
  down the services will be deployed anyway because on another route
  the server will be notified.
  
  Revision  ChangesPath
  1.2   +115 -46   jboss/src/main/org/jboss/system/FarmMemberService.java
  
  Index: FarmMemberService.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/FarmMemberService.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- FarmMemberService.java2001/10/20 04:24:23 1.1
  +++ FarmMemberService.java2001/10/23 07:10:45 1.2
  @@ -10,6 +10,7 @@
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.FilenameFilter;
  +import java.io.FileNotFoundException;
   import java.io.FileOutputStream;
   import java.io.InputStream;
   import java.io.IOException;
  @@ -62,7 +63,7 @@
* /ul
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
  - * @version $Revision: 1.1 $ p
  + * @version $Revision: 1.2 $ p
*
* bRevisions:/b p
*
  @@ -78,11 +79,12 @@
   
  // Attributes 
   
  +   private static ObjectName sFarmMemberService = null;
  +   private static ObjectName sDeployerService = null;
  +   
  /** A callback to the JMX Agent **/
  private MBeanServer mServer;
  
  -   private ObjectName mDeployerService = null;
  -
  private Member mLocal = new Member( null, null );
  
  private String mInitialMembers = null;
  @@ -152,7 +154,7 @@
   RemoteMBeanServer lConnector = lServer.getConnector();
   // Check if the Remote FMS is up an running
   Set lMemberServices = lConnector.queryNames(
  -   new ObjectName( OBJECT_NAME ),
  +   sFarmMemberService,
  null
   );
   if( lMemberServices.size() == 1 ) {
  @@ -166,13 +168,27 @@
 if( !mLocal.equals( lMember ) ) {
log.info( Invoke addMember() on the remote member:  + 
lMember );
lMember.getConnector().invoke(
  -new ObjectName( OBJECT_NAME ),
  +sFarmMemberService,
   addMember,
   new Object[] { pJNDIServerName, pAdaptorJNDIName },
   new String[] { String.class.getName(), 
String.class.getName() }
);
 }
  }
  +   // Not add all listed members here back to the just added server
  +   i = mMembers.iterator();
  +   while( i.hasNext() ) {
  +  Member lMember = (Member) i.next();
  +  if( !lServer.equals( lMember ) ) {
  + log.info( Invoke addMember() on the remote member:  + 
lServer );
  + lServer.getConnector().invoke(
  +sFarmMemberService,
  +addMember,
  +new Object[] { 
lMember.getJNDIServerName(),lMember.getAdaptorJNDIName() },
  +new String[] { String.class.getName(), 
String.class.getName() }
  + );
  +  }
  +   }
   } else {
  if( lMemberServices.size() == 0 ) {
 log.info( No Farm Member Service found on the remote server );
  @@ -201,7 +217,7 @@
   Member lMember = (Member) i.next();
   if( !mLocal.equals( lMember ) ) {
  lMember.getConnector().invoke(
  -  new ObjectName( OBJECT_NAME ),
  +  sFarmMemberService,
 removeMember,
 new Object[] { pJNDIServerName, pAdaptorJNDIName },
 new String[] { String.class.getName(), String.class.getName() }
  @@ -243,7 +259,7 @@
  public FilenameFilter getDeployableFilter() {
 try {
FilenameFilter lFilter = (FilenameFilter) mServer.getAttribute(
  -mDeployerService,
  +sDeployerService,
   DeployableFilter
);
log.info( Deployable Filter is:  + lFilter );
  @@ -280,7 +296,7 @@
  {
 try {
return ( (Boolean) mServer.getAttribute(
  -mDeployerService,
  +sDeployerService,
   Deployed
) ).booleanValue();

[JBoss-dev] CVS update: jboss build.xml


  User: schaefera
  Date: 01/10/23 00:10:45

  Modified:.build.xml
  Log:
  Now the farm does not rely how the members are added it should work any-
  way. The problem was that when a new member is added that the new member
  does not get notified about the existing members which is fixed now.
  Also the deployed services are not pulled from the receiving members
  instead of pushed from the deploying server. Thus if a connection is
  down the services will be deployed anyway because on another route
  the server will be notified.
  
  Revision  ChangesPath
  1.37  +10 -2 jboss/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jboss/build.xml,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- build.xml 2001/10/11 01:41:58 1.36
  +++ build.xml 2001/10/23 07:10:45 1.37
  @@ -10,7 +10,7 @@
   !----
   !-- == --
   
  -!-- $Id: build.xml,v 1.36 2001/10/11 01:41:58 schaefera Exp $ --
  +!-- $Id: build.xml,v 1.37 2001/10/23 07:10:45 schaefera Exp $ --
   
   project default=main name=JBoss/Server
   
  @@ -525,7 +525,15 @@
   !-- Exclude Main, it will go into run.jar --
   exclude name=org/jboss/Main*/
   !-- Exclude JMX Connector stuff we will use the connector JSR for that --
  - exclude name=org/jboss/jmx/**/
  +exclude name=org/jboss/jmx/**/
  +!-- But include this interface because the Farm needs it --
  +include name=org/jboss/jmx/connector/RemoteMBeanServer.class/
  +  /fileset
  +  fileset dir=${build.classes}
  +!-- But include this interface because the Farm needs it --
  +include name=org/jboss/jmx/connector/RemoteMBeanServer.class/
  +include name=org/jboss/jmx/adaptor/rmi/RMIAdaptorImpl.class/
  +include name=org/jboss/jmx/adaptor/interfaces/Adaptor*.class/
 /fileset
   
 fileset dir=${build.resources}
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/main/org/jboss/system/META-INF farm-member-service.xml


  User: schaefera
  Date: 01/10/23 00:10:45

  Modified:src/main/org/jboss/system/META-INF farm-member-service.xml
  Log:
  Now the farm does not rely how the members are added it should work any-
  way. The problem was that when a new member is added that the new member
  does not get notified about the existing members which is fixed now.
  Also the deployed services are not pulled from the receiving members
  instead of pushed from the deploying server. Thus if a connection is
  down the services will be deployed anyway because on another route
  the server will be notified.
  
  Revision  ChangesPath
  1.2   +28 -28jboss/src/main/org/jboss/system/META-INF/farm-member-service.xml
  
  Index: farm-member-service.xml
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/system/META-INF/farm-member-service.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- farm-member-service.xml   2001/10/20 04:24:24 1.1
  +++ farm-member-service.xml   2001/10/23 07:10:45 1.2
  @@ -8,42 +8,42 @@
  
  mbean code=org.jboss.system.FarmMemberService 
 name=JBOSS-SYSTEM:spine=FarmMember
  +  !--
  + Enter the Server-Name of the local JNDI-Server
  + ATTENTION: Must be the same as used below in the
  + list of members because this is part how to the
  + farm figures out if a member is local or not.
  + 
  + Example: www.jboss.org
  +  --
 attribute name=LocalJNDIServerName 
  - !--
  -Enter the Server-Name of the local JNDI-Server
  -ATTENTION: Must be the same as used below in the
  -list of members because this is part how to the
  -farm figures out if a member is local or not.
  -
  -Example: www.jboss.org
  - --
 /attribute
  +  !--
  + Enter the JNDI-Name of the Adaptor used by remote
  + members to connect to this server. Right now only
  + RMI-Adaptors and EJB-Adaptors are supported.
  + 
  + Example: jmx:www.jboss.org:rmi
  +  --
 attribute name=LocalAdaptorJNDIName 
  - !--
  -Enter the JNDI-Name of the Adaptor used by remote
  -members to connect to this server. Right now only
  -RMI-Adaptors and EJB-Adaptors are supported.
  -
  -Example: jmx:www.jboss.org:rmi
  - --
 /attribute
  +  !--
  + Enter the list of all members of the farm (even when
  + the are not started yet). This list must be the same
  + for all members of the same farm.
  + The syntax is:
  + JNDI-Server Name,JNDI-Name of Adaptor
  + 
  + Example:
  + www.jboss.org,jmx:www.jboss.org:rmi
  + www.gugus.net,ejb/jmx/ejb/Adaptor
  + www.example.com,jmx:borg.example.org:rmi
  +  --
 attribute name=Members 
  - !--
  -Enter the list of all members of the farm (even when
  -the are not started yet). This list must be the same
  -for all members of the same farm.
  -The syntax is:
  -JNDI-Server Name,JNDI-Name of Adaptor
  -
  -Example:
  -www.jboss.org,jmx:www.jboss.org:rmi
  -www.gugus.net,ejb/jmx/ejb/Adaptor
  -www.example.com,jmx:borg.example.org:rmi
  - --
 /attribute
  /mbean
   
  -   mbean code=org.jboss.system.FarmAutoDeployer 
name=JBOSS-SYSTEM:service=FarmAutoDeployer
  +   mbean code=org.jboss.deployment.FarmAutoDeployer 
name=JBOSS-SYSTEM:service=FarmAutoDeployer
 attribute name=Deployers
JBOSS-SYSTEM:spine=FarmMember
 /attribute
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Automated JBoss Testsuite Results

2001-10-23 Thread Chris Kimpton


Hi,

--- Hiram Chirino [EMAIL PROTECTED] wrote:
 
 So should I change my default??  I need to good port numbers for
 JBossMQ??  
 Scott, Any ideas??
 

I've changed my test webserver to use port 8030 - so feel free to
leave it at 8090/8091 as far as I am concerned.

Chris

 
 
 On Mon, Oct 22, 2001 at 08:20:55AM -0400, Hiram Chirino wrote:
  
   I just looked up why JBossMQ is failing for the lubega system. 
 Since I 
 just
   added the feature that lets an app connect to MQ without
 needing JNDI, I 
 had
   to pin down the port that the OIL and UIL listen to.
  
   I picked ports 8090 and 8091.  Seems like something allready
 has 8090 
 bound
   on the lubega machine.  Are those bad choices for port
 numbers??
  
   Regards,
   Hiram
  
 


=
Need somewhere to Live in London - http://freeflats.com

__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] cmp: foreign-key-mapping

2001-10-23 Thread Peter Levart


On Monday 22 October 2001 17:54, Dain Sundstrom wrote:
  The following issues apply to foreign-key-mapping ..
 
 
  1) problems with unidirectional relations:
 
  deployment does not work, because the
  JDBCCMRFieldBridge.initRelatedData
  does not find the related cmrField - throws DeploymentException

 I just fixed a bug in this code last night, where the self-relationships
 would not initialize properly. Try the newest code.


If I remember correctly and if I'm not wrong here (I hadn't established that 
for sure), I had the same problem and found out that it was because JBoss 
presumably expects that ejb-relationship-role-name elements are unique across 
the whole jbosscmp-jdbc.xml file. I had two equal ejb-relationship-role-name 
elements in two different relationships and it gave me the same error. When I 
renamed one of them to be unique it worked. Of course you have to be very 
carefull to sync entries between ejb-jar.xml and jbosscmp-jdbc.xml files. If 
names between those two files don't match you can get the same error (It is 
possible that that was the case with me also). Since you brought this issue 
you can test this hypothesis and tell us what you find...

  2) problems with not null constraints on foreign keys:
 
  the JDBCCreateEntityCommand builds an insert statement with
  the cmp fields
  but without the cmr fields .. as far as I know, createEntity
  is the only
  affected command

 I don't think this is correct.  Are you trying to create an EJB that has a
 foreign key relationship to another bean that is guaranteed not be null.
 The only way I can think of to do this is to set the cmr fiend in the
 ejbCreate method, which would give the fk a value during the initial sql
 insert statement.  Unfortunately, it is not legal to set a cmr field during
 the ejbCreate method; You have to wait until ejbPostCreate. Did I
 misinterpret you?


As it currently is the case in JBoss (RH) You can not do anything more in 
ejbPostCreate() that you can do in ejbCreate(). ejbPostCreate() was meant to 
be used for setting up relationships. But as I pointed out in my previous 
postings (Re: [JBoss-dev] Bug in cache) you can not call business methods of 
other beans from ejbPostCreate, since at that time the context of the bean is 
not put into the cache yet and you get into trouble later...

The work around is to not put anything into ejbPostCreate() but instead use 
special business method (can be a home method) that in turn calls create() on 
home interface followed by your intended pos-create processing. Although this 
is portable, JBoss will have to address this issue and allow arbitrary 
processing in ejbPostCreate() method to be EJB 2.0 compliant...

Peter

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] org.jboss.pool.ObjectPool bug?

2001-10-23 Thread Marko trukelj

Title: RE: [JBoss-dev] org.jboss.pool.ObjectPool bug?

-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 22, 2001 5:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] org.jboss.pool.ObjectPool bug?

Aha, looks like I made a mistake. Thanks for the
clarification. I will try
to fix this soon.

Right now, as far as I can tell, these pools are only used for the
connection pooling. Personally, I find the code kind of hard to
understand. I have been thinking of trying to simplify it so that it
exhibits the minimum functionality necessary for connection pools, and
eliminating everything else. (right now it has a lot of speculative
functionality)

Are you using it for other purposes? What do you think of this idea?

I took a look at it if I could use it for pooling threads and stateless sessions for my web app. For example you can have an MBean that represents a thread pool. Then you can have multiple services that do synchronization of databases and things like that and are triggered in a periodic fashion. You can have each one install a job with the Timer service, when it gets TimerNotification it takes a thread from the pool passes it a runnable object, an does what it has to do. You can have 50 services and 5 threads and have a running system if the characteristics of the jobs is right (occasional short executions with more rare lobnger executions that take pool longer)

I first wrote my own ObjectPool, but it wasn't very refined and although it worked fine I was not clear with some concepts so I took a look at org.jboss.pool package. I think it is a great package.

All the speculative functionality is actually fantastically useful. Like PoolEvents that enable a pooled resource to determine by itself when it's time to go back. This is what you can use in pooling threads. Your pool client code can just start a job with the thread, without waiting for it to finish...

So redundancy really comes out of using something very powerful with lots of functionality for something specific that does not use all of that stuff.

But I don't see any overhead or performance penalty because of it. So if you want to limit your view of things there must be a better way then throwing out the functionality.

But I believe your considerations are really in terms of making the code transparent and not buggy. My usage of this package is really a private one, I'm not working on any jboss package, I'm just writing an app. I find the package very useful as it is. If it will change, I'll probably rename the packages and keep using it.

It's X licenced by the way, so usage is really unlimited.

Regards,

Marko.

Thanks
David Jencks

On 2001.10.22 10:34:36 -0400 Marko ?trukelj wrote:

-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 22, 2001 3:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] org.jboss.pool.ObjectPool bug?

I believe you are looking at 3.0 code. In the future please
indicate which
version your comments apply to.

I had HEAD tagged revision 1.6 of ObjectPool in my mind, when I said
'current'. Sorry about not being specific enough.

Having installed the feature you are discussing, I think it
works properly.
The cleanup thread does two activities: removing connections
that have
idletimed out, and removing connections that have been held
onto too long
(GC). In practical terms, only the first is appropriate for
use in an app
server- a transaction timeout should take care of the
crashed while
holding a connection problem.

I agree. ObjectPool however is very generic and can be used for
non-transactional resources. Since it supports garbage collection of
non-returned leased objects separately from cleaning of
IdleTimeout-ed
unused objects in the pool it should work properly for both of these
cases
separately keeping in mind potential broad usage.

IMHO the principal effect is that to get idletimeout to work
as one might
expect you no longer have to set GCEnabled true. This
counterintuitive
state of affairs that is still in 2.4 I think still confuses
many people
trying to clean up their timed out dead connections. Why
should you have
to apparently turn on GC to make idle timeout work???

I don't know about 2.4, since I didn't peek there, but the
code (talking
about rev. 1.6 now) does separate checks for garbage
collection and idle
timeouts collection (this code is in runCleanupandShrink()).

According to this code, garbage collection will occur if
isGCEnabled()
returns false, and isIdletimeoutEnabled() returns true.

This means that there is no way that I can have
IdleTimeouts enabled and
GC
disabled (which is the most common scenario with pooling
DBConnections).
I
can only achieve it by setting minGCIdleTime to a very high

RE: [JBoss-dev] cmp: foreign-key-mapping

2001-10-23 Thread Holger Engels


On Mon, 22 Oct 2001, Dain Sundstrom wrote:

 See my previous email. This shouldn't happen if the relationship is
 specified the right way.
 
 Anyway, thanks for your good emails. You are one of the first users of the
 new cmp 2.0 code, so anything you can tell us will help clean the system for
 normal users.  This escpecially applies to wierd, misleading or non-existant
 message from the system.  In the future try to keep the discussion on the
 list, so users in the future will be able to look at the archive for help.
 

Cool! Seems to work now. Thanks for your help.


But now, I have another question. Are EJBLocalObjects valid parameters for 
finders? I haven't found anything on that in the spec ..

If we agree, that it should be supported, it's only 2 places, that require 
modification:

o JDBCQueryMetaDataFactory.convertToJavaClass(..) seems to use the wrong 
  classloader 

o JDBCDefinedFinderCommand.setParameters(..) should handle local 
  interfaces (obtain the pk) itself and delegate everything else to the 
  JDBCTypeFactory



Holger




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-473999 ] WEB-INF/lib libraries not found


Bugs item #473999, was opened at 2001-10-23 04:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=473999group_id=22866

Category: None
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: WEB-INF/lib libraries not found

Initial Comment:
The bug 421989 has reappeared in 2.4.3.

I have the following problem using the JBoss Final 
2.4.3, combined JBoss+Tomcat setup. 
When deploying a .ear file, with a ejb.jar and 
web.war, none of the libraries in WEB-INF/lib are 
found in the servlet that uses one of those libraries. 
A ClassDefNotFound exception occurs on one of those 
libraries. As a fix for now I've just extracted the 
libraries in WEB-INF/classes in the ejb.jar; these 
classes are found. 

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=473999group_id=22866

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] cmp: foreign-key-mapping

2001-10-23 Thread Holger Engels


On Tue, 23 Oct 2001, Dain Sundstrom wrote:

 
 Glad to see it is working. 
  

I didn't check, if foreign keys are actually written to the db, if I set 
them in the ejbPostCreate method .. I think of, what Peter Levart posted 
on this thread  .. I'll get there soon.


  But now, I have another question. Are EJBLocalObjects valid 
  parameters for 
  finders? I haven't found anything on that in the spec ..
  
  If we agree, that it should be supported, it's only 2 places, 
  that require 
  modification:
  
  o JDBCQueryMetaDataFactory.convertToJavaClass(..) seems to 
  use the wrong 
classloader 
  
  o JDBCDefinedFinderCommand.setParameters(..) should handle local 
interfaces (obtain the pk) itself and delegate everything 
  else to the 
JDBCTypeFactory
 

I declare the following finder in LocalAttributeHome:

  java.util.Collection findByVersion(LocalVersion version);

and have the following section in the jbosscmp descriptor:

  query
query-method
  method-namefindByVersion/method-name
  method-params
method-param
  param-namede.mercatis.egor.ejb.LocalVersion/param-name
/method-param
  /method-params
  declared-sql
fromegor.Version/from
whereversion = {0}/where
ordernumber desc/order
  /declared-sql
/query-method
  /query


JDBCQueryMetaDataFactory.convertToJavaClass tries to load the interface 
class 'de.mercatis.egor.ejb.LocalVersion', but fails with the following 
Exception:

org.jboss.ejb.DeploymentException: Parameter class not found:
  de.mercatis.egor.ejb.LocalEntry

at 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory.convertToJavaClass(JDBCQueryMetaDataFactory.java:178)
at 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory.convertToJavaClasses(JDBCQueryMetaDataFactory.java:142)
at 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory.getQueryMethods(JDBCQueryMetaDataFactory.java:83)
at 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMetaData.init(JDBCEntityMetaData.java:402)
at 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCApplicationMetaData.init(JDBCApplicationMetaData.java:187)
at 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load(JDBCXmlFileLoader.java:72)
at 
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntityMetaData(JDBCStoreManager.java:349)
at 
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.init(JDBCStoreManager.java:104)
at 
org.jboss.ejb.plugins.CMPPersistenceManager.init(CMPPersistenceManager.java:136)
at org.jboss.ejb.EntityContainer.init(EntityContainer.java:313)
at org.jboss.ejb.Application.init(Application.java:198)
at 
org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:377)
...


I tried to find a note in the spec, if local references to related 
entities are valid parameters for a finder .. but found nothing.

After that, I tried to find out, if jbosscmp supports it and came across 
the method setParameters in JDBCDefinedFinderCommand .. if understand the 
code right, it doesn't !?


As a workaround I could easily do without passing entities ... just pass 
the primary key instead. But I think, passing entities as parameters to a 
finder in the local home interface should work in general.

Holger




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-474134 ] Security context lost w/ getEJBObject()


Bugs item #474134, was opened at 2001-10-23 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=474134group_id=22866

Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hussey (mhussey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Security context lost w/ getEJBObject()

Initial Comment:
Windows 2000
JDK 1.3.1

Security context on thread is lost or ignored when 
calling javax.ejb.Handle's getEJBObject() method.  
This incorrectly results in a SecurityException.  This 
simple code works fine with Weblogic, and fails in 
JBoss (note how the thread has the authorization to 
create and use the bean):

Context ctx = new InitialContext();
Object objref = ctx.lookup
(AttachmentBuilder);
Object obj = PortableRemoteObject.narrow
(objref, AttachmentBuilderBeanHome.class);
AttachmentBuilderBeanHome home = 
(AttachmentBuilderBeanHome)obj;

AttachmentHeaderDetail headerDetail=new 
AttachmentHeaderDetail(desc,type,true);
AttachmentBuilderBean statefulBean = 
home.create(domain,headerDetail);

Handle handle = statefulBean.getHandle();

//the following should succeed, but it fails
statefulBean = (AttachmentBuilderBean) 
handle.getEJBObject();

The client and server stack traces follow in that 
order:

java.rmi.ServerException: Could not get EJBObject; 
nested exception is:
java.rmi.ServerException: RemoteException 
occurred in server thread; nested exception is:

javax.transaction.TransactionRolledbackException: 
checkSecurityAssociation; nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null; nested exception is:
java.rmi.RemoteException: 
checkSecurityAssociation; nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null
java.rmi.ServerException: RemoteException occurred in 
server thread; nested exception is:

javax.transaction.TransactionRolledbackException: 
checkSecurityAssociation; nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null; nested exception is:
java.rmi.RemoteException: 
checkSecurityAssociation; nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null
javax.transaction.TransactionRolledbackException: 
checkSecurityAssociation; nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null; nested exception is:
java.rmi.RemoteException: 
checkSecurityAssociation; nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null
java.rmi.RemoteException: checkSecurityAssociation; 
nested exception is:
java.lang.SecurityException: Authentication 
exception, principal=null
java.lang.SecurityException: Authentication exception, 
principal=null
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro
mServer(Unknown Source)
at 
sun.rmi.transport.StreamRemoteCall.executeCall(Unknown 
Source)
at sun.rmi.server.UnicastRef.invoke(Unknown 
Source)
at 
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_
Stub.invokeHome(Unknown Source)
at 
org.jboss.ejb.plugins.jrmp.interfaces.StatefulHandleImp
l.getEJBObject(StatefulHandleImpl.java:124)
at 
com.saba.unittest.bframework.locator.TestDelegate.testC
aseForJBossBug(TestDelegate.java:183)
at 
com.saba.unittest.bframework.locator.TestDelegate.testD
elegateHandle(TestDelegate.java:89)
at 
com.saba.unittest.bframework.locator.TestDelegate.runTe
stCases(TestDelegate.java:73)
at 
com.saba.unittest.bframework.locator.TestDelegate.run
(TestDelegate.java:68)



[AttachmentBuilder] Authentication exception, 
principal=null
[AttachmentBuilder] TRANSACTION ROLLBACK 
EXCEPTION:checkSecurityAssociation; nes
ted exception is:
java.lang.SecurityException: Authentication 
exception, principal=null; n
ested exception is:
java.rmi.RemoteException: 
checkSecurityAssociation; nested exception is:

java.lang.SecurityException: Authentication 
exception, principal=null
[AttachmentBuilder] java.rmi.RemoteException: 
checkSecurityAssociation; nested e
xception is:
[AttachmentBuilder] java.lang.SecurityException: 
Authentication exception, p
rincipal=null
[AttachmentBuilder] java.lang.SecurityException: 
Authentication exception, princ
ipal=null
[AttachmentBuilder] at 
org.jboss.ejb.plugins.SecurityInterceptor.checkSecuri
tyAssociation(SecurityInterceptor.java:168)
[AttachmentBuilder] at 
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(
SecurityInterceptor.java:92)
[AttachmentBuilder] at 
org.jboss.ejb.plugins.StatefulSessionInstanceIntercep
tor.invokeHome
(StatefulSessionInstanceInterceptor.java:123)
[AttachmentBuilder] at 
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxI

[JBoss-dev] Re: javax.transaction.xa.XAException - XAER_OUTSIDE (from forum)

2001-10-23 Thread pra


In reference to:
http://www.jboss.org/forums/thread.jsp?forum=48thread=3150

My first cut at this is that it has to do with the pool. The exception
happens when the pool is trying to clean up and the XA resource is no
longer tied to any sessionID. (any one interested in seeing the trace,
it's 1 M).

Look at this:

[94230] [Thread Pool Worker-2] [JmsXA] Pool org.jboss.jms.ra.JmsManagedConnectio
nFactory-1 [1/2/10] gave out pooled object: org.jboss.jms.ra.JmsManagedConnectio
n@41c92b
[94321] [Thread Pool Worker-0] [JmsXA] Pool org.jboss.jms.ra.JmsManagedConnectio
nFactory-1 [1/2/10] gave out pooled object: org.jboss.jms.ra.JmsManagedConnectio
n@41c92b
[94327] [Thread Pool Worker-0] [JmsXA] Pool org.jboss.jms.ra.JmsManagedConnectio
nFactory-1 [0/2/10] returned object org.jboss.jms.ra.JmsManagedConnection@41c92b
 to the pool.
[94354] [Thread Pool Worker-2] [JmsXA] Pool org.jboss.jms.ra.JmsManagedConnectio
nFactory-1 [0/2/10] returned object org.jboss.jms.ra.JmsManagedConnection@41c92b
 to the pool.

The pool leaves out the same ManagedConnection twice, the one in Worker
0 will ovewrite the one in Worker-2, and when worker two closes there is
no longer a corrext XAResource connected to it. Why this happens I don't
know.

Here what I found in  a more modern BaseConnectionManager:

if ( pool != null ) {
//Avoid race condition whereby con can be reused before clear is called.
ObjectPool mypool = pool;
ManagedConnection mycon = con;
clear();
mypool.releaseObject( mycon );
 }

But here is from the same spot from 2.4:

if(pool != null) {
pool.releaseObject(con);
clear();
}

But I do not know if this is the problem you are having.

//Peter

On 23 Okt, Lars Olsson wrote:
 Peter Antman wrote:
 
 
 Hej, tja det kan du göra. De närmaste dagarna kommer jaga vara rätt
 ordenligt chokad. Dessutom är det Hiram som har gjort all
 transaktionshatering. Jag vet inte ens vad XAER_OUTSIDE är för något.
 
 Men skicka den du får vi se vad den triggar hos mig ;-)
 
 
 OK - tack. Jag bifogar konsol-loggen plus den modifierade log4j.properties
 jag använt.
 
 Applikationen består av ett antal Mdb:er som drivs av samma MDB-klass.
 Varje mdb har ett egen-uppfunnet instans-namn. Log4j-kategorinamnen
 är baserade på dessa instans-namn följt av Hash-code för MDB-klass
 java-instansen.
 
 Lars

-- 

Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems ArchitectWWW: http://www.tim.se
Email: [EMAIL PROTECTED]WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Farming and Clustering

2001-10-23 Thread Bill Burke




Is the new Farming 
stuff from Andreas the thing where a JBoss instance can be booted from a URL 
like http://foo.bar.com/jboss.jcml 
?

I think we should 
market the Farming stuff as a "Clustering" feature. Something 
like

JBoss 3.0 Clustering 
Features:

- Farming, Cluster 
nodes boot up from centralized configuration.- EJB Failover 
and load-balancing
- Cluster-wide JNDI 
with failover and load-balancing
- RMI Failover and 
load-balancing.

Thoughts?

Bill

Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntityInstanceInterceptor.java EntityLockInterceptor.java EntityMultiInstanceInterceptor.java TxInterceptorBMT.java


The change to TxInterceptorBMT breaks MessageDrivenTxInterceptorBMT which
uses associateThread and disassociateThread from TxManager.

I'm not sure of the best way to fix this, if noone says anything in the
next few hours I may roll back this change.

Would anyone object if I added a depends task to the compile targets in 3.0
to make this kind of problem less likely to get committed?

Thanks
david jencks

On 2001.10.21 12:17:07 -0400 Scott M Stark wrote:
   User: starksm 
   Date: 01/10/21 09:17:07
 
   Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
 EntityInstanceInterceptor.java
 EntityLockInterceptor.java
 EntityMultiInstanceInterceptor.java
 TxInterceptorBMT.java
   Log:
   Change org.jboss.tm.TxManager to javax.transaction.TransactionManager
 in
   TxInterceptorBMT and remove all imports of TxManager.
   
   Revision  ChangesPath
   No   revision
   
   
   No   revision
   
   
   1.30.2.5  +1 -2  
jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java
   
   Index: EntityInstanceInterceptor.java
   ===
   RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java,v
   retrieving revision 1.30.2.4
   retrieving revision 1.30.2.5
   diff -u -r1.30.2.4 -r1.30.2.5
   --- EntityInstanceInterceptor.java  2001/10/20
 22:13:22  1.30.2.4
   +++ EntityInstanceInterceptor.java  2001/10/21
 16:17:07  1.30.2.5
   @@ -34,7 +34,6 @@
import org.jboss.ejb.CacheKey;
import org.jboss.logging.log4j.JBossCategory;
import org.jboss.metadata.EntityMetaData;
   -import org.jboss.tm.TxManager;

/**
* The instance interceptors role is to acquire a context representing
   @@ -57,7 +56,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
   -* @version $Revision: 1.30.2.4 $
   +* @version $Revision: 1.30.2.5 $
*
* pbRevisions:/bbr
* pb2001/06/28: marcf/b
   
   
   
   1.5.4.3   +1 -2  
jboss/src/main/org/jboss/ejb/plugins/EntityLockInterceptor.java
   
   Index: EntityLockInterceptor.java
   ===
   RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityLockInterceptor.java,v
   retrieving revision 1.5.4.2
   retrieving revision 1.5.4.3
   diff -u -r1.5.4.2 -r1.5.4.3
   --- EntityLockInterceptor.java  2001/10/20
 22:13:22  1.5.4.2
   +++ EntityLockInterceptor.java  2001/10/21
 16:17:07  1.5.4.3
   @@ -32,7 +32,6 @@
import org.jboss.ejb.CacheKey;
import org.jboss.logging.log4j.JBossCategory;
import org.jboss.metadata.EntityMetaData;
   -import org.jboss.tm.TxManager;

/**
 * The lock interceptors role is to schedule thread wanting to invoke
 method on a target bean
   @@ -50,7 +49,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
   -* @version $Revision: 1.5.4.2 $
   +* @version $Revision: 1.5.4.3 $
*
* pbRevisions:/bbr
* pb2001/07/30: marcf/b
   
   
   
   1.1.4.2   +1 -2  
jboss/src/main/org/jboss/ejb/plugins/EntityMultiInstanceInterceptor.java
   
   Index: EntityMultiInstanceInterceptor.java
   ===
   RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntityMultiInstanceInterceptor.java,v
   retrieving revision 1.1.4.1
   retrieving revision 1.1.4.2
   diff -u -r1.1.4.1 -r1.1.4.2
   --- EntityMultiInstanceInterceptor.java 2001/09/04
 01:51:07  1.1.4.1
   +++ EntityMultiInstanceInterceptor.java 2001/10/21
 16:17:07  1.1.4.2
   @@ -38,7 +38,6 @@
import org.jboss.ejb.CacheKey;
import org.jboss.logging.log4j.JBossCategory;
import org.jboss.metadata.EntityMetaData;
   -import org.jboss.tm.TxManager;

/**
 * The instance interceptors role is to acquire a context representing
   @@ -46,7 +45,7 @@
 *
 *
 * @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
   - * @version $Revision: 1.1.4.1 $
   + * @version $Revision: 1.1.4.2 $
 *
 * pbRevisions:/bbr
 * pb2001/08/08: billb/b
   
   
   
   1.16.4.2  +4 -4  jboss/src/main/org/jboss/ejb/plugins/TxInterceptorBMT.java
   
   Index: TxInterceptorBMT.java
   ===
   RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/TxInterceptorBMT.java,v
   retrieving revision 1.16.4.1
   retrieving revision 1.16.4.2
   diff -u -r1.16.4.1 -r1.16.4.2
   --- TxInterceptorBMT.java   2001/10/20 22:13:22 1.16.4.1
   +++ TxInterceptorBMT.java   2001/10/21 16:17:07 1.16.4.2
   @@ -16,6 +16,7 @@

import

[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/jdbc PreparedStatementInPool.java


  User: d_jencks
  Date: 01/10/23 11:39:10

  Modified:src/main/org/jboss/pool/jdbc Tag: Branch_2_4
PreparedStatementInPool.java
  Log:
  Backported bug fix from 2.5, removed npe if StatementInPool is closed more than once
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.1.1.2.1 +4 -1  
jbosspool/src/main/org/jboss/pool/jdbc/Attic/PreparedStatementInPool.java
  
  Index: PreparedStatementInPool.java
  ===
  RCS file: 
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/jdbc/Attic/PreparedStatementInPool.java,v
  retrieving revision 1.1.1.1
  retrieving revision 1.1.1.1.2.1
  diff -u -r1.1.1.1 -r1.1.1.1.2.1
  --- PreparedStatementInPool.java  2001/05/15 07:58:24 1.1.1.1
  +++ PreparedStatementInPool.java  2001/10/23 18:39:09 1.1.1.1.2.1
  @@ -418,7 +418,10 @@
   }
   
   public void close() throws SQLException {
  -con.statementClosed(this);
  +if (con != null) 
  +{
  +con.statementClosed(this);
  +}   
   super.clearFields();
   con = null;
   impl = null;
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS tags in 2.4 branch???


I'm trying to be a good samaritan and backport a couple of bug fixes from 3
to the 2.4 branch and I don't want to break the cvs Rel tag numbering
scheme.

After I check in my 2 fixed files, in jbosspool, am I supposed to tag them
with Rel_2_4_4_4? I get this number by looking at
org.jboss.ejb.plugins.TxInterceptorBMT and seeing it's last branch Rel tag
as Rel_2_4_4_3. I notice there are some branch revisions that are not tip
that have no Rel_xxx tags. Does that mean they weren't tagged?  What
happens if I neglect to tag my changes? Will someone elses tag find them
before the next 2.4 release or will they be lost forever (until someone
notices).

After I tag the jbosspool directory, I am supposed to copy the new jar to
jboss and tag everything there also with the same tag?  Again, what happens
if I neglect to do this?

Many thanks for any light that can be thrown on this.
David Jencks

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Farming and Clustering




Hi Geeks

No, the actual farming stuff is to enable an 
administrator to setup a farm
(a set of individual computers) allowing him to 
deploy a service on all
of the participating members.

For sure the features of the farming must go 
somehow into clustering
because the deployment on a logical server must end 
up in a deployment
on all the physical boxes.

At the enda cluster is a special form of a 
farm !!

My idea of a farm is that it works similar to the 
Internet allowing to
deploy a service without having a centralized 
authority (the farm
tries any path until the service gets deployed 
except the node is
completely isolated from any other member of the 
farm).

The deployment from a 
centralizedconfiguration server is just
a small step.

Andy

  - Original Message - 
  From: 
  Bill 
  Burke 
  To: Jboss-Development@Lists. 
  Sourceforge. Net 
  Sent: Tuesday, October 23, 2001 10:42 
  AM
  Subject: [JBoss-dev] Farming and 
  Clustering
  
  Is the new Farming 
  stuff from Andreas the thing where a JBoss instance can be booted from a URL 
  like http://foo.bar.com/jboss.jcml 
  ?
  
  I think we should 
  market the Farming stuff as a "Clustering" feature. Something 
  like
  
  JBoss 3.0 
  Clustering Features:
  
  - Farming, Cluster 
  nodes boot up from centralized configuration.- EJB 
  Failover and load-balancing
  - Cluster-wide 
  JNDI with failover and load-balancing
  - RMI Failover and 
  load-balancing.
  
  Thoughts?
  
  Bill

[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/connector BaseConnectionManager.java


  User: d_jencks
  Date: 01/10/23 12:25:25

  Modified:src/main/org/jboss/pool/connector Tag: Branch_2_4
BaseConnectionManager.java
  Log:
  backported bugfix from 3.0 branch
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.1.1.2.1 +34 -22
jbosspool/src/main/org/jboss/pool/connector/Attic/BaseConnectionManager.java
  
  Index: BaseConnectionManager.java
  ===
  RCS file: 
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/connector/Attic/BaseConnectionManager.java,v
  retrieving revision 1.1.1.1
  retrieving revision 1.1.1.1.2.1
  diff -u -r1.1.1.1 -r1.1.1.1.2.1
  --- BaseConnectionManager.java2001/05/15 07:58:24 1.1.1.1
  +++ BaseConnectionManager.java2001/10/23 19:25:25 1.1.1.1.2.1
  @@ -28,6 +28,7 @@
* handles connection pools, and provides listener implementations
* for LocalTransactions, XAResources, and no transactions.
* @author Aaron Mulder [EMAIL PROTECTED]
  + * @author David Jencks [EMAIL PROTECTED]
*/
   public abstract class BaseConnectionManager implements ConnectionManager {
   public final static String POOL_CONFIGURATION_KEY=PoolConfiguration;
  @@ -166,6 +167,7 @@
   protected ObjectPool pool;
   protected ManagedConnection con;
   
  +
   protected ConnectionListener(ObjectPool pool, ManagedConnection con) {
   this.pool = pool;
   this.con = con;
  @@ -314,6 +316,9 @@
* error occurs.  The connection is not returned immediately on
* close because some connections using LocalTransaction may not
* be able to maintain separate state for separate transactions.
  + *
  + * This implementation uses Synchronization.afterCompletion 
  + * to commit the local transaction, since there is no XAResource.  
*/
   protected class SharedLocalConnectionListener extends ConnectionListener 
implements Synchronization, ConnectionEventListener {
   private Transaction trans;
  @@ -383,23 +388,14 @@
   }
   
   if(getHandleCount() = 0) {
  -if(pool != null) {
  -pool.releaseObject(con);
  -} else {
  -try {
  -con.destroy();
  -} catch(ResourceException e) {
  -e.printStackTrace();
  -}
  -}
  -clear();
  +done(pool, con);   // Clean up and return to pool or destroy.
   } else {
   trans = null;
   local = null;
   }
   }
   
  -public void beforeCompletion() {
  +public void beforeCompletion() { 
   }
   
   /**
  @@ -416,6 +412,8 @@
   clear();
   }
   
  +
  +
   /**
* Only return connection to the pool if this is the last handle to
* the current ManagedConnection, and there's no TX.  This could
  @@ -426,16 +424,7 @@
   connectionHandleClosed(evt.getConnectionHandle());
   if(removeHandle() = 0) {  // If this was the last handle...
   if(trans == null) {// And the transaction is over...
  -if(pool != null) { // Put back in the pool...
  -pool.releaseObject(con);
  -} else {
  -try {  // Or get rid of entirely.
  -con.destroy();
  -} catch(ResourceException e) {
  -e.printStackTrace();
  -}
  -}
  -clear();
  +done(pool, con);   // Clean up and return to pool or destroy.
   }
   }
   }
  @@ -464,6 +453,26 @@
   trans = null;
   local = null;
   }
  +
  +private void done(ObjectPool pool, ManagedConnection con) {
  +//Clear the ConnectionListener _before_ returning to the pool
  +//to avoid a race in which the connection is reused before the
  +//connection listener is cleared,
  +// and this method calls con.destroy() on null.
  +clear();
  +//clear cleared the pool and con instance variables, which is why we 
  +//passed them in.
  +if(pool != null) {
  +pool.releaseObject(con);
  +} else {
  +try {
  +con.destroy();
  +} catch(ResourceException e) {
  +e.printStackTrace();
  +}
  +}
  +}
  +
   }
   
   /**
  @@ -578,8 +587,11 @@
   
   // Clean up if pooled or if transaction is over
   if(pool !=

RE: [JBoss-dev] CVS tags in 2.4 branch???

2001-10-23 Thread Bill Burke


You must tag all of JBoss from the root directory with Rel_2_4_4_4.  Don't
forget to put in a ChangeNote for 2.4.4.  I always seem to forget myself :)

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of David
 Jencks
 Sent: Tuesday, October 23, 2001 3:10 PM
 To: jboss-dev
 Subject: [JBoss-dev] CVS tags in 2.4 branch???


 I'm trying to be a good samaritan and backport a couple of bug
 fixes from 3
 to the 2.4 branch and I don't want to break the cvs Rel tag numbering
 scheme.

 After I check in my 2 fixed files, in jbosspool, am I supposed to tag them
 with Rel_2_4_4_4? I get this number by looking at
 org.jboss.ejb.plugins.TxInterceptorBMT and seeing it's last branch Rel tag
 as Rel_2_4_4_3. I notice there are some branch revisions that are not tip
 that have no Rel_xxx tags. Does that mean they weren't tagged?  What
 happens if I neglect to tag my changes? Will someone elses tag find them
 before the next 2.4 release or will they be lost forever (until someone
 notices).

 After I tag the jbosspool directory, I am supposed to copy the new jar to
 jboss and tag everything there also with the same tag?  Again,
 what happens
 if I neglect to do this?

 Many thanks for any light that can be thrown on this.
 David Jencks

 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-474206 ] OutOfMemoryError when sending to Queue


Bugs item #474206, was opened at 2001-10-23 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=474206group_id=22866

Category: JBossMQ
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: OutOfMemoryError when sending to Queue

Initial Comment:
I'm trying to send 5000 hello TextMessages to a Queue.

Before this finishes the server runs out of memory, and
throws an OutOfMemoryError.  This causes the client
untold problems and the server never really comes back
to a stable state, even after the client disconnect.

Using latest CVS pull.

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=474206group_id=22866

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: CVSROOT modules

2001-10-23 Thread Hiram Chirino


  User: chirino 
  Date: 01/10/23 14:14:04

  Modified:.modules
  Log:
  JBossMQ Standalone needed the hsqldb lib
  
  Revision  ChangesPath
  1.70  +1 -0  CVSROOT/modules
  
  Index: modules
  ===
  RCS file: /cvsroot/jboss/CVSROOT/modules,v
  retrieving revision 1.69
  retrieving revision 1.70
  diff -u -r1.69 -r1.70
  --- modules   2001/10/11 23:14:23 1.69
  +++ modules   2001/10/23 21:14:04 1.70
  @@ -159,6 +159,7 @@
thirdparty/gjt \
thirdparty/gnu \
thirdparty/hsql \
  + thirdparty/hsqldb \
thirdparty/junit \
thirdparty/oswego \
thirdparty/javagroups \
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/lib jbosspool.jar


  User: d_jencks
  Date: 01/10/23 14:22:38

  Modified:src/lib  Tag: Branch_2_4 jbosspool.jar
  Log:
  jbosspool.jar binary with 2 backported bugfixes
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.4.3   +426 -466  jboss/src/lib/Attic/jbosspool.jar
  
Binary file
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Change Notes-474301 ] backported 2bug fixes to jbosspool