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:
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:
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 CacheS
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 sav
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 sa
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 fo
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 Mes
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/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 a
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/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.
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: 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 be
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:
>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
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]
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
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/pm/file MessageLog.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage methods.
Revision ChangesPath
1.7 +46 -45jboss
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 metho
:)
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 us
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. Sourceforge
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.
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, Novembe
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: Tu
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
[AutoDe
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,
>
> 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?
Yep.
> My question is do you really need to go through the container
> chain, since
> it goes
|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 o
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
==
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 can
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
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 t
Patches item #481533, was opened at 2001-11-13 16:19
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481533&group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Tulley (jtulle
--- Begin Message ---
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: Jul
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]
|[mailto:[EM
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 transac
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
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
-Dsnapshot-export-cvs.disable=true
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
-Dsnapsh
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 r
Patches item #481521, was opened at 2001-11-13 15:30
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481521&group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Tulley (jtulle
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
===
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
The 2.4 shutdown code is not applicable to 3.0 as the services layer
has changed significantly, and still has more to do.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Jeff Tulley" <[EMAIL PROTECTED]>
To
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
order
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),
som
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:[EMAI
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 contrib/iiop/src/main
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 +3
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: 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
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.
M
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
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
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:
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 getFoo()
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:
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
org.jboss.security.S
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
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,
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
jbo
Patches item #481461, was opened at 2001-11-13 12:40
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481461&group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Tulley (jtulle
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: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 key
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 twice.
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
>
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
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 going
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
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
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 e
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: /cvsro
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
>
> 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
>
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
STA
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
Bugs item #481358, was opened at 2001-11-13 09:07
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=481358&group_id=22866
Category: JBossTX
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel OConnor (docodan)
Assigned to: Nobody/Anon
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: D
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
> -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 o
> 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
Does this mean that the dependencies can go like this?
JBOSS-SYSTEM:service=DefaultPartition
JBOSS-SYSTEM:service=DefaultPartition
rather than like this:
JBOSS-SYSTEM:service=HASessionState
JBOSS-SYSTEM:service=HAJNDI
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
Hello,
> Unfortunately at this moment in time it is not possible to hot-deploy a
> clustered service that depends on state-transfer. You can hot-deploy
> clustered EJBs though, well at least for SLSB and EBs. Sacha, what about
> SFSBs?
Yes, it is possible.
Next step on my todo list is to speak
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: ServiceConfigu
86 matches
Mail list logo
