User: d_jencks
Date: 01/11/12 23:55:00
Modified:src/main/org/jboss/system ServiceConfigurator.java
Log:
Fixed dumb bug in mbean-ref-list handling
Revision ChangesPath
1.6 +21 -17jboss/src/main/org/jboss/system/ServiceConfigurator.java
Index:
Hello!
I just wanted to know if somebody has a straight answer. I'm using JBoss 3.0
alpha with CMP 2.0.
The first time I reference let's say 10 Entity Beans after a JBoss restart it
takes approx. 5 seconds to retrieve data from them. The second and subsequent
requests to return data from the
Does this mean that the dependencies can go like this?
mbean code=org.jboss.ha.framework.server.ClusterPartition
name=JBOSS-SYSTEM:service=DefaultPartition
/mbean
mbean code=org.jboss.ha.hasessionstate.server.HASessionStateService
name=JBOSS-SYSTEM:service=HASessionState
Hello!
I just wanted to know if somebody has a straight answer. I'm
using JBoss 3.0
alpha with CMP 2.0.
The first time I reference let's say 10 Entity Beans after a
JBoss restart it
takes approx. 5 seconds to retrieve data from them. The
second and subsequent
requests to return
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Tuesday, November 13, 2001 9:03 AM
To: Sacha Labourey
Cc: Bill Burke; David Jencks; Andreas Schaefer;
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] RE: Deployment exception on
Have you thought of profiling the code to determine what's taking so long?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf
Of Dain Sundstrom
Sent: 13 November 2001 15:49
To: 'Peter Levart'; [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] loading 10 EBs
Well, I'm not focusing on this kind of optimization currently, and it takes
approximately 1s to access 20 beans on my machine. Down the road, I'll
profile the code.
-dain
-Original Message-
From: Tim Fox [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 13, 2001 10:27 AM
To: Dain
On 2001.11.13 11:34:39 -0500 Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
David
Jencks
Sent: Tuesday, November 13, 2001 9:03 AM
To: Sacha Labourey
Cc: Bill Burke; David Jencks; Andreas Schaefer;
[EMAIL PROTECTED]
Hi Geeks
I don't think the mbean-ref list will WORK. As you said the ClusterPartition
will be created, attributes are set BUT it won't be started.
AFAIK ClusterPartition needs to initialize JChannel before the other HA-
service can start, doesn't it? Yeah, but then this initialization is NOT
Look, I apologize for this breaking the cluster code, I will do whatever I
can to help fix it. I would like to know if you have any suggestions on
how I could have provided more warning about the effects or found out that
the code was breaking. I've been talking about this change for
more
Can't we just deprecate the use of init() right now? It would make all of
our lives much easier and the RabbitHole alpha can go forward with a working
clustering engine. In the meantime, Sacha and I can work with the
JavaGroups guys to eliminate the need for 2 phase initialization.
Bill
User: mnf999
Date: 01/11/13 10:05:01
Modified:src/docs/developers head.jsp
Log:
Revision ChangesPath
1.4 +1 -1 newsite/src/docs/developers/head.jsp
Index: head.jsp
===
RCS file:
On 2001.11.13 13:07:22 -0500 Bill Burke wrote:
Can't we just deprecate the use of init() right now? It would make all
of
our lives much easier and the RabbitHole alpha can go forward with a
working
clustering engine. In the meantime, Sacha and I can work with the
JavaGroups guys to
User: tmcsys
Date: 01/11/13 10:23:27
Modified:src/xdocs/howto howtossl.xml
Log:
Add Jetty SSL configuration
Revision ChangesPath
1.2 +27 -13manual/src/xdocs/howto/howtossl.xml
Index: howtossl.xml
Well, see the code I sent under separate cover, but here's how i think you
can get exactly the same code execution sequence:
[ClusterPartition created, configured, but not started]
HAJNDI created, start does nothing
(other needed mbeans also created and started similarly)
Now the dependencies
Damn the reply-to button
-Mensaje original-
De: Ignacio Coloma [mailto:[EMAIL PROTECTED]]
Enviado el: martes, 13 de noviembre de 2001 18:28
Para: Dain Sundstrom
Asunto: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called
Could it be the database cache? Just guessing.
-Mensaje
Bugs item #481358, was opened at 2001-11-13 09:07
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=481358group_id=22866
Category: JBossTX
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel OConnor (docodan)
Assigned to:
Part of the problem with communicating architecture changes is that
discussions are embedded in threads whose subject ultimiately is
virtually meaningless for the concluding remarks. Also, the conclusions
about what is to be done are often left implied based on the thread
arguments.
If your
Like this?
http://www.mail-archive.com/jboss-development%40lists.sourceforge.net/msg11085.html
david jencks
On 2001.11.13 13:43:12 -0500 Scott M Stark wrote:
Part of the problem with communicating architecture changes is that
discussions are embedded in threads whose subject ultimiately is
User: dsundstrom
Date: 01/11/13 12:15:24
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCRemoveEntityCommand.java
Log:
Fixed a bug where if a related entity was related two ways with cascade
delete, the command would attempt to remove the entity
User: dsundstrom
Date: 01/11/13 12:19:07
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationshipRoleMetaData.java
Log:
Added an error message for when a relationship is defined for a non-existant
entity.
Eliminated the weird foreign
User: charles_chan
Date: 01/11/13 12:29:15
Modified:src/etc/conf/cluster jbossmq-service.xml
Log:
- Incorporate old fixes from default/ to cluster/
Revision ChangesPath
1.2 +33 -7 jbossmq/src/etc/conf/cluster/jbossmq-service.xml
Index: jbossmq-service.xml
User: dsundstrom
Date: 01/11/13 12:43:50
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCTypeFactory.java
Log:
Fixed lame bug where the wrong hashtable was used to determine if a type is
a known dependent value class.
Revision ChangesPath
1.7 +2 -2
Jasper requires tools.jar to be available to it.
Should I:
1. copy it from my java distrib into lib/ext with the Jetty jars at
build time (is the jar arch independent)
2. try to get it on the JBOSS_CLASSPATH and hope Jetty/Jasper can see
it...
3. find another way - suggestions ?
In short,
That was a good start to which there was one reply that was a question
by you asking if the change to the jbossmq layer would work. There were
other messages threads in which elements of this was discussed, but I
never got the feeling from these that a decision had been made as to the
efficacy of
I'm sure I'm overlooking the key issues here, but
is it currently possible to use JBoss (3.0a) with Tomcat (4.0x)? I got the
catalina plug-in down but can't build it. It's apparently associated with the
JBoss 2.4, not 3.0. More specifically, it's looking for classes like
1) worked fine for me...
-Original Message-
From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 10:05 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] RH: tools.jar (javac)...
Jasper requires tools.jar to be available to it.
Should I:
1. copy
User: reverbel
Date: 01/11/13 13:28:24
Modified:iiop/src/main/org/jboss/iiop/rmi InterfaceAnalysis.java
Log:
Fixed bug in calculateOperationAnalysisMap(). This bug shows up for
non-remote interfaces containing methods that follows the JavaBean
attribute pattern (i.e., a
No, the catalina service has not been updated to work with 3.0 yet.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Brian Sondergaard
To: [EMAIL PROTECTED]
Sent: Tuesday, November 13, 2001 1:12 PM
Subject:
Hey all,
I just ported the old 2.4.x version of Stop.java over to Rabbit Hole, then realized
that there is a Shutdown.java command that actually does a full shutdown. So, before
I chuck the new version of Stop.java as a fun academic exercise, I was wondering
if the stop functionality is
User: dsundstrom
Date: 01/11/13 14:26:25
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql
EJBQLParser.java SQLTarget.java
Log:
Remove typo that caused the literal WHERE to be case sensitive.
Made idenfification variables case insensitive as required
For those MQ heads out there.
I thought it was about time we started pooling our message objects, since
the JMS server uses so many of them. I have just about finished
implementing a very simple object pooling structure for the various types of
spy messages and message reference objects.
User: tmcsys
Date: 01/11/13 14:26:50
Modified:src/docs petstore_frames.html
Log:
Adapt to new site design
Revision ChangesPath
1.4 +3 -4 newsite/src/docs/petstore_frames.html
Index: petstore_frames.html
On 2001.11.13 16:11:47 -0500 Scott M Stark wrote:
That was a good start to which there was one reply that was a question
by you asking if the change to the jbossmq layer would work. There were
other messages threads in which elements of this was discussed, but I
never got the feeling from
User: reverbel
Date: 01/11/13 14:43:28
Modified:iiop/src/main/org/jboss/iiop/rmi OperationAnalysis.java
Log:
Fixed bug in the analysis of operations of non-remote interfaces:
RMIIIOPViolationException should not be thrown in this case.
Revision ChangesPath
1.3
Patches item #481461, was opened at 2001-11-13 12:40
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=481461group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Tulley (jtulley)
User: reverbel
Date: 01/11/13 14:47:08
Modified:iiop/src/main/org/jboss/iiop CorbaORBServiceMBean.java
Log:
Changed base class for RH: was org.jboss.util.ServiceMBean, now is
org.jboss.system.ServiceMBean.
Revision ChangesPath
1.4 +2 -2
Just a warning too, a side effect of this is I made a very slight change to
the way the file PM writes its messages to disk, so any old files from the
file PM won't work after you download the change, you will have to delete
them.
-Original Message-
From: David Maplesden [mailto:[EMAIL
Hmm, now I see you are asking if stop all without undeploy is useful. I
don't think so: it is very apt to interfere with the stopping/restarting of
mbeans based on their mbean-ref dependencies. In particular, unless you
stop mbeans in the reverse order of their deployment (actually startup),
some
I've never seen the stop.java, but the shutdown now proceeds by calling
shutdown on ServiceController, which undeploys all mbeans(registered with
it) in reverse order of their deployment. So I think the Stop.java would
duplicate this functionality but worse, since it has no way to know what
I am reading the CMR 2.0 code and I see that it makes intensive use of the
CacheKey creation (which I guess is normal).
In cachekey, the change introduced by Bill, i.e. to enforce copy semantics
is a very slow operation. It involves a full serialization. This has
negative effects.
1- it slows
User: tmcsys
Date: 01/11/13 15:12:19
Modified:src/docs/common jboss-tomcat.jsp
Log:
Fix the picture
Revision ChangesPath
1.3 +3 -2 newsite/src/docs/common/jboss-tomcat.jsp
Index: jboss-tomcat.jsp
User: mnf999
Date: 01/11/13 15:41:20
Modified:src/main/org/jboss/ejb CacheKey.java
Log:
The performance of the copy semantics is just too expensive, if we want to enforce
the copy semantics in the future (commented out here) then we should put that in some
cache class that can
User: tmcsys
Date: 01/11/13 15:43:17
Added: src/metadata website-application-nosnaps.xml
Log:
Allow users to build website.ear without building and including snapshots.war.
To build website and manual:
build.sh -Dmodules=website,manual -Dsnapshot.disable=true
User: tmcsys
Date: 01/11/13 15:44:42
Modified:.build.xml
Log:
Allow users to build website.ear without building and including snapshots.war.
To build website and manual:
build.sh -Dmodules=website,manual -Dsnapshot.disable=true
It wasn't Bill that added this. It was first added in 1.2 and then expanded
in
1.8, more copying added in 1.10, etc. This whole thing started to create an
idiot proof key, which cannot be done. Instead we have a big fat expensive
key that is killing performance. Let the user live and die by their
Dain,
I am reading your stuff and I see that you use the invocation chain to do
ADD_RELATION on the bean you are working with. Is this what you were
talking about the other day?
My question is do you really need to go through the container chain, since
it goes through the security and
The basic cachekey is not expensive, in fact it is more lightweight than a
regular key, creating the serialized representation is expensive, and again
afair it was bill correcting the copy problem on key reuse inside one VM.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
---BeginMessage---
David Maplesden wrote:
1) worked fine for me...
Have you tried it on different architectures?
My concern is that if I do the build on Linux, the tools.jar from my 1.3.1
distrib may not work on e.g. a Mac etc...
Jules
-Original Message-
From: Julian
How can it be lightweight when it has to make a deep copy of the true key
using serialization? Bill's change was to add yet another copy, so now there
is the copying of the true key into a MarshalledObject followed by a copy of
this
using MarshalledObject.get(). Your change just removed both of
No I haven't and I see now what you mean, I didn't read what you put
carefully enough. Still you might be able to do it this way, IIRC we used
to distribute javac in a javac.jar that was distributed with JBoss to
different platforms and it seemed to work OK.
I thought the only reason we weren't
That is how both the bundled tomcat and standalone tomcat handles this.
You have to have the JDK tools.jar, or jikes, or some other compiler
configured
as part of the installation. Since we can't bundle tools.jar and javac.jar
is
just a black box we don't want to include since it source for it
User: mnf999
Date: 01/11/13 17:19:40
Modified:src/main/org/jboss/ejb CacheKey.java
Log:
Warming up :)
Revision ChangesPath
1.18 +7 -6 jboss/src/main/org/jboss/ejb/CacheKey.java
Index: CacheKey.java
|How can it be lightweight when it has to make a deep copy of the true key
|using serialization? Bill's change was to add yet another copy, so
because the precalculated stuff is used in the subsequent calls.
|now there
|is the copying of the true key into a MarshalledObject followed by
|a copy
So make it even more efficient by not using the MarshalledObject at all.
I'm not saying get rid of CacheKey, get rid of its use of MarshalledObject
and use the id directly.
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED];
Sent: Tuesday,
touch /var/lib/jboss/deploy/foo.jar
..
[AutoDeployer] Auto deploy of file:/home.local/var/lib/jboss/deploy/foo.jar
[J2EE Deployer Default] Deploy J2EE application:
file:/home.local/var/lib/jboss/deploy/foo.jar
[AutoDeployer] Deployment failed:file:/home.local/var/lib/jboss/deploy/foo.jar
One thing I have noticed it that the newbie programmers that are most likely
to not implement equals and hashCode correctly, don't use a custom primary
key. Instead they use an Integer, Long, or String.
-dain
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent:
rereading the equals implementation,
It compares the equals of a marshalled object and I am left wondering how
fast that really is.
I guess it is a byte[] comparison under it? I don't know.
marcf
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Tuesday,
Yes it does use byte[] comparisons in a for loop. Let me give you
a push in my direction. We know there is a performance drop in 2.4.4
that has yet to be resolved, but profiling shows it is related to
interaction
with the entity cache and that the CacheKey ctor ends up being the largest
hotspot.
well,
then you don't win,
but I don't win either
today is a crappy day
but the fix is relevant
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, November 13, 2001 8:55 PM
|To: Jboss-Development@Lists.
:)
you win
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, November 13, 2001 8:44 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: Re: [JBoss-dev] CacheKey copy semantics and speed
|
|
|
|Yes it does
User: dmaplesden
Date: 01/11/13 17:53:40
Modified:src/main/org/jboss/mq/server BasicQueue.java
MessageCache.java MessageReference.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage
User: dmaplesden
Date: 01/11/13 17:53:40
Modified:src/main/org/jboss/mq SpyBytesMessage.java
SpyEncapsulatedMessage.java SpyMapMessage.java
SpyMessage.java SpyObjectMessage.java
SpyQueueSender.java SpySession.java
User: dmaplesden
Date: 01/11/13 17:53:40
Modified:src/main/org/jboss/mq/cluster/jms ClusterTopicSession.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage methods.
Revision ChangesPath
1.5 +9
Ok, but all of that time was really due to the removal of the
MarshalledObject.get(). Running with the CacheKey implementation
pre the copy gives basically the same time as the non-MarshalledObject
version:
1 minute 48 seconds
- Original Message -
From: Scott M Stark [EMAIL PROTECTED]
From: Charles Chan [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
Subject: Re: JBossMQ PM XAResource interface
Date: Tue, 13 Nov 2001 18:29:40 -0800 (PST)
My initial idea with XML is simple... Just create an
XMLMessage type (extended from TextMessage). Create a
JBoss daily test results
SUMMARY
Number of tests run: 187
Successful tests: 146
Errors:26
Failures: 15
[time of test: 14 November 2001 3:12 GMT]
[java.version:
User: dbudworth
Date: 01/11/13 19:52:15
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCStartCommand.java
Log:
Added check for relatedCMRField existance in execute.
Was assuming there was one and crashing with NPE when attempting to deploy
1:1 cmr
JBoss daily test results
SUMMARY
Number of tests run: 187
Successful tests: 148
Errors:25
Failures: 14
[time of test: 14 November 2001 3:59 GMT]
[java.version:
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm PersistenceManagerMBean.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm/file PersistenceManager.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
User: chirino
Date: 01/11/13 20:23:27
Modified:src/etc/conf/default jbossmq-service.xml
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm/jdbc PersistenceManager.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/server MessageCache.java
MessageCacheMBean.java MessageReference.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the
User: chirino
Date: 01/11/13 20:24:08
Added: src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm/rollinglogged
PersistenceManager.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for
User: chirino
Date: 01/11/13 20:24:08
Added: src/main/org/jboss/mq/pm CacheStore.java
CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for
David Jencks,
I've got a deployment question for you. I just finished adjusting MQ's
MessageCache so that it uses a CacheStore interface to store/load/remove
messages from secondary storage. We should be able to get some performance
gains by having the PersistenceManager implement the
Patches item #481521, was opened at 2001-11-13 15:30
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=481521group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Tulley (jtulley)
JBoss daily test results
SUMMARY
Number of tests run: 172
Successful tests: 135
Errors:23
Failures: 14
[time of test: 14 November 2001 5:25 GMT]
[java.version:
JBoss daily test results
SUMMARY
Number of tests run: 187
Successful tests: 148
Errors:25
Failures: 14
[time of test: 14 November 2001 6:23 GMT]
[java.version:
Patches item #481533, was opened at 2001-11-13 16:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=481533group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Tulley (jtulley)
82 matches
Mail list logo
