RE: [JBoss-dev] JMS Explanation Needed
The behaviour you describe in both situations is obviously not desired but it is all that is implemented in JBossMQ at this time ( I know this because I wrote it ). In other words the problems you are seeing are not brought about by your lack of understanding or a bug as such, it simply implemented that way. When you raised the first point I had a look at the source and unfortunately there is no 5 minute fix to either problem. The solution needs some thought, a little coding and quite a bit of testing and I am no longer able to do this myself. In my earlier reply (trying to be helpful) I made a couple of suggestions for an approach I think will solve the problem. I strongly suggest you either look at these problems yourself and supply a patch for them or enter them as bugs at sourceforge, that way one of the core team will be more likely to look at them and try to solve the problem. Oh yeah, if (when you don't commit) you actually rollback the session the message will become available for redelivery. In other words don't just terminate your client (if you can avoid it) but always commit or rollback your session. I think simply closing the session will also work as this will rollback any uncommitted transactions. The case JBossMQ doesn't handle well is when the client simply crashes and goes away without cleaning up. I hope this helps. David -Original Message- From: Joshua D. Cough [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 6:56 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JMS Explanation Needed Could someone please explain to me the default behavior in the following scenario? I create a transacted Session, receive a single message from a Queue, I DONT COMMIT, and I terminate my client. That message remains in the Queue, but cannot be received by any other Session. If I restart JBOSS, the message can then be received by some other Session. Is this what is supposed to happen? Is there any way that I can receive that Message again in a different Session without having to restart JBOSS? and/or, is this a bug? The same situation exists if I fail to call acknowledge from a non transacted session. I am the same person who sent out the bug saying that session.recover() calls session.rollback() even though it cannot do that due to the if statements that are set up in each method. No one has had a chance to fix that bug yet. --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
I have had a 5 minute look at this problem and how to fix it. It is
non-trivial (though not that hard)
to fix but I don't have time (sorry) to fix and test the change myself.
Basically the session needs to keep a track of all unacknowledged messages
received by its various consumers so that it can negatively acknowledge them
on a recover and the server will redeliver them. Currently this is done in
transacted mode by the transaction manager but not done when not in
transacted mode. Anyway this will require a change to the
SpyMessageConsumer receive methods which currently by-pass the session. It
will also require a change to the SpyMessage acknowledge method to let the
session know when the message has been acknowledged.
David.
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 12:53 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
|It is impossible to call recover in SpySession.java
|
|here is why:
|
|
|if ( transacted ) {
| throw new IllegalStateException( The session is
transacted );
| }
|if ( !transacted ) {
| throw new IllegalStateException( The session is not
|transacted
|);
| }
|
|This obviously doesnt make sense.
LOL
marcf
|nontransacted session and have my unacknowledged messages
|redelivered. Here
|is the code that needs to be fixed:
|
|==
|==
|=
|
| //Rollback a transacted session
|public synchronized void rollback()
| throws JMSException {
|
| synchronized ( runLock ) {
|
| if ( spyXAResource != null ) {
| throw new
javax.jms.TransactionInProgressException( Should
|not
|be call from a XASession );
| }
| if ( closed ) {
| throw new IllegalStateException( The session
is closed );
| }
| if ( !transacted ) {
| throw new IllegalStateException( The session is not
|transacted
|);
| }
|
| // rollback transaction
| try {
| connection.spyXAResourceManager.endTx(
currentTransactionId,
|true );
| connection.spyXAResourceManager.rollback(
|currentTransactionId
|);
| } catch ( javax.transaction.xa.XAException e ) {
| throw new SpyJMSException( Could not rollback, e );
| } finally {
| try {
|currentTransactionId =
|connection.spyXAResourceManager.startTx();
| } catch ( Exception ignore ) {
| }
| }
|
| }
|}
|
|
|public synchronized void recover()
| throws JMSException {
| if ( closed ) {
| throw new IllegalStateException( The session is
closed );
| }
| if ( transacted ) {
| throw new IllegalStateException( The session is
transacted );
| }
|
| rollback();
|
|}
|
|
|___
|
|Don't miss the 2002 Sprint PCS Application Developer's Conference
|August 25-28 in Las Vegas --
http://devcon.sprintpcs.com/adp/index.cfm
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|
|_
|Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp.
|
|
|___
|
|Don't miss the 2002 Sprint PCS Application Developer's Conference
|August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Nothing like a cry for help to get me interested. From a brief look at the source and from what I can remember from my work on this stuff the problem is in JBossMQ SpySession class. From what I can see the sendMessage method needs to be synchronized and I think that will solve your problem. What I guess is happening is that another thread is calling commit at the same time this thread is calling sendMessage and hence the currentTransactionID is invalid when it gets passed through to the XAResourceManager. So you either need to patch SpySession sendMessage so that it is synchronized or patch the client code (the code calling the JBossMQ stuff) so that it doesn't have threads calling commit on the session at the same time other threads are using the queueSender.send() method. I must admit any client where the order of these two operations is indeterminate is in dangerous territory as they won't know which transaction their message sends are ending up in, which probably why the bug hasn't shown up before. I guess the client code in this case is the JMS RA stuff (which I know nothing about) so it might need investigating. David. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 7:37 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA I spent the last week upgrading my service to JBoss3, which made the configuration much easier for me to managed (no more hacks in jboss.conf for extra classpaths and such), but I am still seeing an occasional Invalid Invalid transaction id. when using the JMS RA and JBossMQ. I changed my model so that my client (invoked inside of a NotSupported MDB) uses a SFSB with a referece to java:/JmsXA RA, mostly to get around serialization issues, but whatever. A test sceneraio creates 1000 request messages, each of which will send back 1+n responses, where n could vary from 2-? depending on how long the request took to process. So lets assume that for each request that there are 3 responses, so there are 5000 messages, 1000 to a request queue and 4000 to a response queue. I am seeing an occasional problem sending responses back where several responses in a row will fail with this Invalid transaction id. Each request/response(s) cyle is exactly the same... so why could some have invalid tx id's and others have valid ones? Below is a trace from one of the exceptions, though I doubt it is of much use. Any idea what might be causing this? Is this likely to be a JMS RA problem or JBossMQ problem? Any insight would be helpful, I really need to track this problem down. --jason snip com.boldfish.does.worker.WorkerException: failed to send message; - nested throwable is: javax.jms.JMSException: Invalid transaction id. + nested throwable: javax.jms.JMSException: Invalid transaction id. at org.jboss.mq.SpyXAResourceManager.addMessage(SpyXAResourceMana ger.java:71) at org.jboss.mq.SpySession.sendMessage(SpySession.java:395) at org.jboss.mq.SpyQueueSender.internalSend(SpyQueueSender.java:118) at org.jboss.mq.SpyQueueSender.send(SpyQueueSender.java:68) at com.boldfish.ben.system.adapter.jms.ejb.QueueSenderAdapterEJB. send(QueueSenderAdapterEJB.java:340) at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.in voke(StatefulSessionContainer.java:823) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInter ceptor.java:129) at org.jboss.resource.connectionmanager.CachedConnectionIntercept or.invoke(CachedConnectionInterceptor.java:147) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invok e(StatefulSessionInstanceInterceptor.java:266) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Abstrac tTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxI nterceptorCMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT .java:61) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionC ontainer.java:380) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerIntercep tor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInter ceptor.java:73) at
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
And another thing, I can't 100% remember because its been a while since I read it but I think the JMS spec says that Sessions should not be shared by multiple threads. Crazy in my opinion but there you go... -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 8:31 AM To: [EMAIL PROTECTED]; David Maplesden; '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Nothing like a cry for help to get me interested. =) So you either need to patch SpySession sendMessage so that it is synchronized or patch the client code (the code calling the JBossMQ stuff) so that it doesn't have threads calling commit on the session at the same time other threads are using the queueSender.send() method. I must admit any client where the order of these two operations is indeterminate is in dangerous territory as they won't know which transaction their message sends are ending up in, which probably why the bug hasn't shown up before. I guess the client code in this case is the JMS RA stuff (which I know nothing about) so it might need investigating. So, this does indeed get interesting... my client code is calling a SFSB which has a JMS RA, which has the SpySession. I do have a timer thread sending back periodic stats with the same SFSB (my bad) which the main thread uses... but shouldn't the SFSB detect this and throw an exception about the concurent usage? Shit, my EJB has gotten rusty... only one thread should beable to use a SFSB at a time... or really one thread per bean in general right... I need to read the latest spec again. =( I can fix my client to sync, but I am wondering if there is something we can do to make the cause of this problem more obvious for others. So, for the spec experts out there, is there something that should be done wrt the SFSB in this case? And is there any reason why SpySession.sendMessage() should NOT be synchronized? Thanks David. --jason David. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 7:37 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA I spent the last week upgrading my service to JBoss3, which made the configuration much easier for me to managed (no more hacks in jboss.conf for extra classpaths and such), but I am still seeing an occasional Invalid Invalid transaction id. when using the JMS RA and JBossMQ. I changed my model so that my client (invoked inside of a NotSupported MDB) uses a SFSB with a referece to java:/JmsXA RA, mostly to get around serialization issues, but whatever. A test sceneraio creates 1000 request messages, each of which will send back 1+n responses, where n could vary from 2-? depending on how long the request took to process. So lets assume that for each request that there are 3 responses, so there are 5000 messages, 1000 to a request queue and 4000 to a response queue. I am seeing an occasional problem sending responses back where several responses in a row will fail with this Invalid transaction id. Each request/response(s) cyle is exactly the same... so why could some have invalid tx id's and others have valid ones? Below is a trace from one of the exceptions, though I doubt it is of much use. Any idea what might be causing this? Is this likely to be a JMS RA problem or JBossMQ problem? Any insight would be helpful, I really need to track this problem down. --jason snip com.boldfish.does.worker.WorkerException: failed to send message; - nested throwable is: javax.jms.JMSException: Invalid transaction id. + nested throwable: javax.jms.JMSException: Invalid transaction id. at org.jboss.mq.SpyXAResourceManager.addMessage(SpyXAResourceMana ger.java:71) at org.jboss.mq.SpySession.sendMessage(SpySession.java:395) at org.jboss.mq.SpyQueueSender.internalSend(SpyQueueSender.java:118) at org.jboss.mq.SpyQueueSender.send(SpyQueueSender.java:68) at com.boldfish.ben.system.adapter.jms.ejb.QueueSenderAdapterEJB. send(QueueSenderAdapterEJB.java:340) at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.in voke(StatefulSessionContainer.java:823) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInter ceptor.java:129) at org.jboss.resource.connectionmanager.CachedConnectionIntercept or.invoke(CachedConnectionInterceptor.java:147
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I understand the pros and cons, I am just saying what I feel. You can outvote me if you wish. David -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 2:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Think about it this way... somebody creates a simple servlet that creates a unit of work by sending 2 messages and then commits the work. Somebody that does not know the spec to will might cache that session in a instance variable. If 2 requests come in at the same time, they will screw each other up seriously. The first request might commit his 2 messages and some of the messages the 2nd thread was creating. So the question is, should we try to make the session thread-safe for the power users out there that MIGHT know how stuff is working under the covers. Or should we make the session check conncurent access better to let beginer user know when he has potentialy made a semantical error. Regards, Hiram From: David Maplesden [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Date: Fri, 24 May 2002 13:36:43 +1200 I hate to disagree with Scott and Hiram but I feel that just because the spec says Sessions should only be used in 1 thread does not neccessarily mean that we should restrict their usage as such. I know a Session only makes sense in the context of a single process, but this might still entail the usage of a couple of different threads. I don't think we should place any restrictions on the usage of Sessions as long as they work, and I believe making sendMessage() synchronized will do the trick. This can be just one more area where JBoss goes Beyond the Spec but hey I leave the final decision up to someone else. David. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Workaround for CL stuff
Ok, I'm not the expert on this stuff either, but in an effort to help out here is my explanation of what I think is happening. The major problem (and the starting point of the whole thing) is that when classes are being loaded the JVM can call loadClassInternal() on multiple class loaders at the same time. This method is synchronized and so immediately two different threads have locked two different class loaders, let us say Thread A has locked ClassLoader A and Thread B has locked ClassLoader B. Now loadClassInternal simply calls the loadClass method of the respective class loader and so if you have a class loader (like the JBoss UnifiedClassLoader) which can delegate to other class loaders (via UnifiedLoaderRepository) to load classes you can get a situation where Thread A now wants to access synchronized methods in ClassLoader B and Thread B wants to access synchronized methods in ClassLoader A and neither can because of the earlier locks already gained, hence deadlock. This bought about by the fact that the private loadClassInternal() method is synchronized and can be called pretty much at any time by the JVM. The only way you could work around the problem is if you could synchronize on some common object before loadClassInternal is called, but since this is called rather unpredictably directly from the JVM I don't know if there is any way to do this. Why the F*K loadClassInternal() is synchronized is a complete mystery as all it does is call loadClass() which can be synchronized if it needs to be. David -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 8:47 AM To: Bordet, Simone; Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Workaround for CL stuff Simone, I still don't see the problem clearly, please help me. | Where does the loadClassInternal() intervene? | |It is called by the JVM when it has to resolve class dependencies. ok |Say you have class A that has a data member of class B. |When a CL is asked to load A, it inspects the class and see that |it needs to load also B. This is done at native level, and while a |classloader is loading class A, the JVM calls loadClassInternal() |on the *same* thread and on the *same* classloader to load class |B; this may trigger another call and so on recursively. If the ok |classloader delegates to some other classloader you can have deadlock. this I don't see, you seem to jump to the conclusion, can you please walk me? |There is a call for loadClass, some more call on java code, then a |call to native method, and if the native method decides it has no |sufficient information it calls back java code, it's java - |native - java. | |loadClass() | ... |defineClass() [is this the native one ?] | loadClassInternal() |loadClass() So if loadClassInternal fails it goes to the loadClass() in our stack? cl1.loadClass(A) A refers to B cl1.loadClassInternal(B) fails cl1.loadClass(B) is then called. is that correct? And then ...? |A typical scenario for me was this one: jar1 with a set of related |classes, and jar2 with another set, but the 2 jars interacts and |are loaded by different classloaders. When something is started |in jar1, not all classes in the jar are loaded; the start |triggers loading from jar2 that happens to load some class from |jar1 that was not already loaded. I am lost. Let's say jar1:set1:cl1 has classes A and C jar2:set2:cl2 has class B A and B reference C A starts up loads A, loads class internal C (I assume it finds it) but it is not in the repository (internal call). In a mono threaded JBoss, B is loaded up by cl2.load(B), which doesn't find it, starts up, needs to load C and so cl2.loadCint(B) fails goes to cl2.load(B) which goes repository.load(B) which then goes to cl1.load(B) which should work. Let's imagine a multithreaded JBoss where the service A spawns a thread. please help marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.350 / Virus Database: 196 - Release Date: 4/17/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.350 / Virus Database: 196 - Release Date: 4/17/2002 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossMQ Problem with Topics
Dropped, as per the JMS spec. -Original Message- From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 11:59 AM To: Hiram Chirino Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossMQ Problem with Topics Hi Geeks When a message is sent to a non-durable, non-persistent topic and no subscriber are available is then the message kept in memory or dropped ? Thanx x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.350 / Virus Database: 196 - Release Date: 4/17/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.350 / Virus Database: 196 - Release Date: 4/17/2002 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] javax.management.timer.Timer looks questionable
I don't know about this time around but originally (i.e. about 6 months ago) I got rid of the oswego stuff because it caused JBossMQ to deadlock completely when under high load. One of the major stabilising factors in moving from JBossMQ 0.8 to JBossMQ 1.0 was the rewriting of the thread handling stuff and subsequent removal of the oswego code. I must admit the reason I had to remove the code rather than attempt to fix it was that I didn't understand completely how their semaphore based locking scheme worked and where it was going wrong when the deadlock occurred. Also the need for a thread pool effectively vanished at the time when I had finished simplifying the MQ delivery mechanisms so I didn't investigate more fully. David. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 8:43 AM To: [EMAIL PROTECTED]; Adrian Brock Subject: Re: [JBoss-dev] javax.management.timer.Timer looks questionable Juts currious why we have been trying to get rid of oswego usage? I have seen mail like this before for JBossMQ, but I don't really understand why. These classes are designed very well and are maintained by and expert in this field... Anyways, just currious. --jason Quoting Adrian Brock [EMAIL PROTECTED]: Hi Scott, This shows my lack of knowledge about sleep(). I thought sleep(0) was wait forever :-( I will fix the linear traversal when I remove the dependency on the oswego class. Regards, Adrian The problem with the server spinning after running the testsuite on linux was due to the javax.management.timer.Timer calling sleep(0) which apparently is basically a noop and so a busy wait for new timers resulted. In general the implementation of this class looks questionable as it is using linear traversals and inefficient waiting. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12884 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.344 / Virus Database: 191 - Release Date: 4/2/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.344 / Virus Database: 191 - Release Date: 4/2/2002 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Depends usage and boot service.xml
Possibly a stupid question... what about classpath codebase=file:bla/bla2/ archives=bla.jar ? Does this include bla.jar from the specified directory or is it invalid? David Finally the explicit classpath usage is slightly different. codebase is always referenced to the jboss-home classpath codebase=lib/ext archives=* includes everyone in the lib/ext (as it used to and is included) classpath codebase=bla archives=bla2.jar includes jboss-home/bla/bla2.jar classpath codebase=http://myserver; archives=bla.jar includes http://myserver/bla.jar classpath codebase=file:bla/bla2/ includes the directory marcf --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged PersistenceManager.java
User: dmaplesden
Date: 01/12/16 12:05:41
Modified:src/main/org/jboss/mq/pm/rollinglogged
PersistenceManager.java
Log:
fix for (very rare) concurrent modification exception.
Revision ChangesPath
1.15 +6 -2
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- PersistenceManager.java 2001/11/14 04:23:27 1.14
+++ PersistenceManager.java 2001/12/16 20:05:41 1.15
@@ -39,7 +39,7 @@
*
* @author David Maplesden ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version$Revision: 1.14 $
+ * @version$Revision: 1.15 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
org.jboss.mq.pm.PersistenceManager, PersistenceManagerMBean
{
@@ -913,7 +913,11 @@
protected void checkCleanup() throws JMSException
{
- Iterator logs = new ArrayList(messageLogs.keySet()).iterator();
+
+ Iterator logs = null;
+ synchronized(messageLogs){
+ logs = new ArrayList(messageLogs.keySet()).iterator();
+ }
while (logs.hasNext())
{
checkCleanup((SpyTxLog)logs.next());
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tests: 129 or 203?
There has been a bit of discussion about this. The current theory is that there are 203. When it reports only 129 it is because something has hung and the remaining tests didn't get run. Notice that after every report of 129 tests we also get a JBoss Shutdown didn't work message but we don't seem to get one after the 203. David -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 10:19 AM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] Tests: 129 or 203? Ok, I see that our tests are running again which is good because I will know that the next commit from me will be the one breaking the stuff :) Does anyone know why some tests report 129 succesful tests and others 203 doesn't sound really solid. I am working solely on the testbean stuff to debug my proxy invocation so I haven't looked at the problems yet, so if anyone knows, please let me know marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tests: 129 or 203?
-Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 12:17 PM To: David Maplesden; Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Tests: 129 or 203? |There has been a bit of discussion about this. The current theory is that |there are 203. When it reports only 129 it is because something has hung |and the remaining tests didn't get run. Notice that after every report of meaning no one knows what the fuck is going on :) Basically yes. I looked at one of the logs on http://lubega.com and saw this (if it is any help to anyone). Basically looks to me like all the tests are running but they all screw up after the one bad one and then all the reports break as well, hence the reporting of only 129 tests. Interestingly the thread dump that is created when the same same test run fails to stop shows the shutdown hook is blocked waiting on a monitor in Class.forName(). It doesn't take a genius to guess this is probably what is blocking all the others tests as well. David (edited) test log file * Searching for build.xml ... Buildfile: /disk/orig/home/lubega/jbossro/jboss-all/build/build.xml SNIP SNIP tests-standard-unit: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/reports [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/log [junit] Running org.jboss.test.util.test.SchedulerUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.696 sec [junit] Running org.jboss.test.bmp.test.BmpUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 20.101 sec [junit] Running org.jboss.test.cts.test.BmpUnitTestCase [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 38.243 sec [junit] Running org.jboss.test.cts.test.StatefulSessionUnitTestCase [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 10.503 sec [junit] Running org.jboss.test.cts.test.StatelessSessionUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.488 sec [junit] Running org.jboss.test.dbtest.test.DbTypesUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.996 sec [junit] Running org.jboss.test.idgen.test.IdGenUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.569 sec [junit] Running org.jboss.test.jbossmq.test.JBossMQUnitTestCase [junit] Tests run: 24, Failures: 0, Errors: 0, Time elapsed: 161.499 sec [junit] Running org.jboss.test.jbossmq.test.SelectorParserUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.064 sec [junit] Running org.jboss.test.jbossmq.test.ConnectionUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.943 sec [junit] Running org.jboss.test.jmsra.test.RaQueueUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 15.442 sec [junit] Running org.jboss.test.jmsra.test.RaTopicUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 13.219 sec [junit] Running org.jboss.test.jmsra.test.RaSyncRecUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.314 sec [junit] Running org.jboss.test.jmx.test.ConnectionFactoryLoaderUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.615 sec [junit] Running org.jboss.test.jmx.test.DeployServiceUnitTestCase [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 11.954 sec [junit] Running org.jboss.test.jrmp.test.CustomSocketsUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.84 sec [junit] Running org.jboss.test.lock.test.SpinUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 21.958 sec [junit] Running org.jboss.test.mdb.test.MDBUnitTestCase [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 37.614 sec [junit] Running org.jboss.test.naming.test.ENCUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.899 sec [junit] Running org.jboss.test.naming.test.ExternalContextUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.901 sec [junit] Running org.jboss.test.naming.test.SimpleUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.897 sec [junit] Running org.jboss.test.readahead.test.ReadAheadUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 34.306 sec [junit] Running org.jboss.test.testbean.test.BeanUnitTestCase SNIP SNIP [junit] Test OK, 183 tests run, congratulations [junit] Tests took 33225 milliseconds [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 31.977 sec [junit] Running org.jboss.test.web.test.WebIntegrationUnitTestCase [junit] HttpClient.reponse = HTTP/1.1 200 OK [junit] HttpClient.reponse = HTTP/1.1
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource JBossConnectionListenerImpl.java
User: dmaplesden
Date: 01/12/13 14:20:57
Modified:src/main/org/jboss/resource JBossConnectionListenerImpl.java
Log:
reduce overly verbose logging
Revision ChangesPath
1.6 +5 -3
jbosscx/src/main/org/jboss/resource/JBossConnectionListenerImpl.java
Index: JBossConnectionListenerImpl.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/JBossConnectionListenerImpl.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JBossConnectionListenerImpl.java 2001/11/26 03:24:52 1.5
+++ JBossConnectionListenerImpl.java 2001/12/13 22:20:57 1.6
@@ -19,7 +19,7 @@
* @author Toby Allsopp ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
* @seeConnectionManagerFactory
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class JBossConnectionListenerImpl
implements JBossConnectionListener
@@ -53,7 +53,8 @@
*/
public void connectionHandleIssued(Object connection)
{
- category.debug(Connection handle ' + connection +
+ if( category.isTraceEnabled() )
+ category.trace(Connection handle ' + connection +
' issued by connection manager ' + cm + ' from mcf ' +
mcf + ');
}
@@ -65,7 +66,8 @@
*/
public void connectionHandleClosed(Object connection)
{
- category.debug(Connection handle ' + connection +
+ if( category.isTraceEnabled() )
+ category.trace(Connection handle ' + connection +
' closed from connection manager ' + cm + ' from mcf ' +
mcf + ');
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java
User: dmaplesden
Date: 01/12/13 14:22:09
Modified:src/main/org/jboss/mq SpySession.java
SpyMessageConsumer.java
Log:
reduce overly verbose logging
Revision ChangesPath
1.8 +4 -11 jbossmq/src/main/org/jboss/mq/SpySession.java
Index: SpySession.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpySession.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SpySession.java 2001/11/14 01:53:40 1.7
+++ SpySession.java 2001/12/13 22:22:09 1.8
@@ -33,7 +33,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public abstract class SpySession
implements Session, XASession {
@@ -223,11 +223,10 @@
public synchronized void close()
throws JMSException {
- // allow other threads to process before closing this session
- // Patch submitted by John Ellis (10/29/00)
-// Thread.yield();
- cat.debug(Session closing.);
+ if( cat.isDebugEnabled() )
+ cat.debug(Session closing.);
+
synchronized ( runLock ) {
if ( closed ) {
@@ -275,8 +274,6 @@
throw new IllegalStateException( The session is not transacted );
}
- cat.debug( Session: commit() );
-
//Don't deliver any more messages while commiting
synchronized ( runLock ) {
@@ -313,8 +310,6 @@
throw new IllegalStateException( The session is not transacted );
}
- cat.debug( Session: rollback() );
-
// rollback transaction
try {
connection.spyXAResourceManager.endTx( currentTransactionId, true );
@@ -339,8 +334,6 @@
if ( transacted ) {
throw new IllegalStateException( The session is transacted );
}
-
- cat.debug( Session: recover() );
rollback();
1.15 +2 -2 jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- SpyMessageConsumer.java 2001/12/12 22:08:07 1.14
+++ SpyMessageConsumer.java 2001/12/13 22:22:09 1.15
@@ -23,7 +23,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.14 $
+ * @version$Revision: 1.15 $
*/
public class SpyMessageConsumer
implements MessageConsumer, SpyConsumer, Runnable
@@ -150,7 +150,7 @@
if ( mes != null ) {
return mes;
}
- cat.debug( SpyMessageConsumer: receive in messages.wait() );
+
messages.wait();
}
} catch ( InterruptedException e ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server MessageReference.java MessageCache.java
User: dmaplesden
Date: 01/12/13 14:22:43
Modified:src/main/org/jboss/mq/server MessageReference.java
MessageCache.java
Log:
implement more efficient LRUCache
Revision ChangesPath
1.7 +4 -4 jbossmq/src/main/org/jboss/mq/server/MessageReference.java
Index: MessageReference.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageReference.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MessageReference.java 2001/11/26 06:33:12 1.6
+++ MessageReference.java 2001/12/13 22:22:43 1.7
@@ -25,7 +25,7 @@
* /ul
*
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
- * @version$Revision: 1.6 $
+ * @version$Revision: 1.7 $
*/
public class MessageReference implements Comparable
{
@@ -41,7 +41,7 @@
}
}
- public Long referenceId;
+ public long referenceId;
public MessageCache messageCache;
public SpyMessage hardReference;
public MessageSoftReference softReference;
@@ -59,7 +59,7 @@
}
//init and reset methods for use by object pool
- void init(MessageCache messageCache, Long referenceId, SpyMessage message)
+ void init(MessageCache messageCache, long referenceId, SpyMessage message)
{
this.messageCache = messageCache;
this.hardReference = message;
@@ -206,7 +206,7 @@
{
try
{
- return referenceId.equals(((MessageReference) o).referenceId);
+ return referenceId == ((MessageReference) o).referenceId;
} catch (Throwable e)
{
return false;
1.10 +152 -18 jbossmq/src/main/org/jboss/mq/server/MessageCache.java
Index: MessageCache.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageCache.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- MessageCache.java 2001/12/12 03:24:58 1.9
+++ MessageCache.java 2001/12/13 22:22:43 1.10
@@ -24,13 +24,14 @@
* later.
*
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
- * @version$Revision: 1.9 $
+ * @author a href=mailto:[EMAIL PROTECTED];David Maplesden/a
+ * @version$Revision: 1.10 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
// The cached messages are orded in a LRU linked list
- private LinkedList lruCache = new LinkedList();
-
+ private LRUCache lruCache = new LRUCache();
+
// Provides a Unique ID to MessageHanles
private long messageCounter = 0;
int cacheHits = 0;
@@ -66,8 +67,8 @@
synchronized (this)
{
MessageReference mh = new MessageReference();
- mh.init(this, new Long(messageCounter++), message);
- lruCache.addLast(mh);
+ mh.init(this, messageCounter++, message);
+ lruCache.addMostRecent(mh);
totalCacheSize++;
validateSoftReferenceDepth();
@@ -109,7 +110,7 @@
{
while (true)
{
- //
+//
//log.trace(Waiting for a reference to get GCed.);
// Get the next soft reference that was canned by the GC
Reference r = referenceQueue.remove(1000);
@@ -124,7 +125,7 @@
}
if( log.isTraceEnabled() )
log.trace(soft reference cache size is now: +softRefCacheSize);
-
+
//log.trace(Validating soft reference count.);
validateSoftReferenceDepth();
}
@@ -170,12 +171,13 @@
if (chnageCount 1)
{
log.debug(Converting + chnageCount + hard ref to to soft refs);
-Iterator iter = lruCache.iterator();
-for (int i = 0; i chnageCount iter.hasNext(); i++)
+Node leastRecent = lruCache.getLeastRecent();
+for (int i = 0; i chnageCount leastRecent != null; i++)
{
- MessageReference mr = (MessageReference) iter.next();
+ MessageReference mr = (MessageReference) leastRecent.data;
mr.makeSoft();
- iter.remove();
+ lruCache.remove(leastRecent);
+ leastRecent = lruCache.getLeastRecent();
}
}
//log.trace(run lock release);
@@ -193,8 +195,9 @@
synchronized (this)
{
if (wasHard)
-lruCache.remove(mh);
- lruCache.addLast(mh);
+lruCache.makeMostRecent(mh);
+ else
+lruCache.addMostRecent(mh
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java
Ok, I know this was a bit naughty.
Part of the reason I did it (and I know this is not a good excuse) is that
we have a small problem in the build, introduced when you (I think it was
you) changed the Connection class to use org.jboss.logging.Logger.
The problem is that Connection (along with SpySession and SpyMessageConsumer
etc) are client side classes and org.jboss.loggging.Logger is not included
in the jbossmq-client.jar. This means that jbossmq-client.jar is no longer
sufficient by itself for people to connect to JBossMQ, a CNF exception
occurs.
The reason I am mentioning it is that I have had a look at the way
jbossmq-client is built and I am not sure of the best way to resolve this
problem, what do you suggest?
David
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 14, 2001 11:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq
SpySession.java SpyMessageConsumer.java
Don't just drop the debug msgs, change them to trace msgs using
the org.jboss.logging.Logger rather than org.apache.log4j.Category.
- Original Message -
From: David Maplesden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 13, 2001 2:22 PM
Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq
SpySession.java SpyMessageConsumer.java
User: dmaplesden
Date: 01/12/13 14:22:09
Modified:src/main/org/jboss/mq SpySession.java
SpyMessageConsumer.java
Log:
reduce overly verbose logging
Revision ChangesPath
1.8 +4 -11 jbossmq/src/main/org/jboss/mq/SpySession.java
Index: SpySession.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpySession.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SpySession.java 2001/11/14 01:53:40 1.7
+++ SpySession.java 2001/12/13 22:22:09 1.8
@@ -33,7 +33,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public abstract class SpySession
implements Session, XASession {
@@ -223,11 +223,10 @@
public synchronized void close()
throws JMSException {
- // allow other threads to process before closing
this session
- // Patch submitted by John Ellis (10/29/00)
-// Thread.yield();
- cat.debug(Session closing.);
+ if( cat.isDebugEnabled() )
+ cat.debug(Session closing.);
+
synchronized ( runLock ) {
if ( closed ) {
@@ -275,8 +274,6 @@
throw new IllegalStateException( The session is not
transacted );
}
- cat.debug( Session: commit() );
-
//Don't deliver any more messages while commiting
synchronized ( runLock ) {
@@ -313,8 +310,6 @@
throw new IllegalStateException( The session is not
transacted );
}
- cat.debug( Session: rollback() );
-
// rollback transaction
try {
connection.spyXAResourceManager.endTx(
currentTransactionId, true );
@@ -339,8 +334,6 @@
if ( transacted ) {
throw new IllegalStateException( The session is
transacted );
}
-
- cat.debug( Session: recover() );
rollback();
1.15 +2 -2
jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- SpyMessageConsumer.java 2001/12/12 22:08:07 1.14
+++ SpyMessageConsumer.java 2001/12/13 22:22:09 1.15
@@ -23,7 +23,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.14 $
+ * @version$Revision: 1.15 $
*/
public class SpyMessageConsumer
implements MessageConsumer, SpyConsumer, Runnable
@@ -150,7 +150,7 @@
if ( mes != null ) {
return mes;
}
- cat.debug( SpyMessageConsumer: receive in
messages.wait() );
+
messages.wait();
}
} catch ( InterruptedException e ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java
No, only jbossmq-client.jar (and a couple of things like jnp-client.jar and log4j.jar) should be needed by JBossMQ clients, the other classes are server-side only. -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Friday, December 14, 2001 1:01 PM To: JBossDev (E-mail) Subject: Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java I added the Logger and TracePriority classes to the jboss-client.jar. Isn't this required by JBossMQ clients? If not, then these classes need to be redundantly added to jbossmq-client.jar - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Thursday, December 13, 2001 2:57 PM Subject: RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java Ok, I know this was a bit naughty. Part of the reason I did it (and I know this is not a good excuse) is that we have a small problem in the build, introduced when you (I think it was you) changed the Connection class to use org.jboss.logging.Logger. The problem is that Connection (along with SpySession and SpyMessageConsumer etc) are client side classes and org.jboss.loggging.Logger is not included in the jbossmq-client.jar. This means that jbossmq-client.jar is no longer sufficient by itself for people to connect to JBossMQ, a CNF exception occurs. The reason I am mentioning it is that I have had a look at the way jbossmq-client is built and I am not sure of the best way to resolve this problem, what do you suggest? David -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Friday, December 14, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java Don't just drop the debug msgs, change them to trace msgs using the org.jboss.logging.Logger rather than org.apache.log4j.Category. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILClientILService.java
User: dmaplesden
Date: 01/12/13 16:22:43
Modified:src/main/org/jboss/mq/il/oil OILClientILService.java
Log:
debug - trace logging
Revision ChangesPath
1.5 +6 -4 jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java
Index: OILClientILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- OILClientILService.java 2001/09/26 05:02:28 1.4
+++ OILClientILService.java 2001/12/14 00:22:43 1.5
@@ -30,13 +30,13 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
* @created August 16, 2001
*/
public class OILClientILService implements Runnable, org.jboss.mq.il.ClientILService
{
- static org.apache.log4j.Category cat =
org.apache.log4j.Category.getInstance(OILClientILService.class);
+ static org.jboss.logging.Logger cat =
org.jboss.logging.Logger.getLogger(OILClientILService.class);
// Attributes
final static int m_close = 2;
final static int m_deleteTemporaryDestination = 1;
@@ -93,7 +93,8 @@
try
{
- cat.debug(Waiting for the server to connect to me);
+ if( cat.isDebugEnabled() )
+cat.debug(Waiting for the server to connect to me);
// We may close() before we get a connection so we need to
// periodicaly check to see if we were !running.
serverSocket.setSoTimeout(1000);
@@ -147,7 +148,8 @@
try
{
-cat.debug(Waiting for a messgage from the server);
+if( cat.isTraceEnabled() )
+ cat.trace(Waiting for message from server.);
code = in.readByte();
}
catch (java.io.InterruptedIOException e)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool ObjectPool.java
User: dmaplesden
Date: 01/12/13 16:24:21
Modified:src/main/org/jboss/pool ObjectPool.java
Log:
debug - trace logging
Revision ChangesPath
1.10 +22 -21jbosspool/src/main/org/jboss/pool/ObjectPool.java
Index: ObjectPool.java
===
RCS file: /cvsroot/jboss/jbosspool/src/main/org/jboss/pool/ObjectPool.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ObjectPool.java 2001/12/07 03:40:39 1.9
+++ ObjectPool.java 2001/12/14 00:24:21 1.10
@@ -649,8 +649,8 @@
if ( result instanceof PooledObject ) {
( ( PooledObject )result ).addPoolEventListener( this );
}
- if ( log.isDebugEnabled() ) {
- log.debug( Pool + this + gave out pooled object: +
result );
+ if ( log.isTraceEnabled() ) {
+ log.trace( Pool + this + gave out pooled object: +
result );
}
return result;
} catch ( ConcurrentModificationException e ) {
@@ -675,16 +675,16 @@
}
if ( shouldBlock ) {
-if ( log.isDebugEnabled() ) {
- log.debug( Pool + this + waiting for a free object );
+if ( log.isTraceEnabled() ) {
+ log.trace( Pool + this + waiting for a free object );
}
synchronized ( this ) {
try {
if ( ourTimeout 0 ) {
wait( ourTimeout );
ourTimeout = end - System.currentTimeMillis();
- if ( log.isDebugEnabled() ) {
-log.debug( Pool waiting for (millis): + ourTimeout );
+ if ( log.isTraceEnabled() ) {
+log.trace( Pool waiting for (millis): + ourTimeout );
}
if (ourTimeout = 0) {
shouldBlock = false; //don't wait again
@@ -699,8 +699,8 @@
break;
}
}
- if ( log.isDebugEnabled() ) {
- log.debug( Pool + this + couldn't find an object to return! );
+ if ( log.isTraceEnabled() ) {
+ log.trace( Pool + this + couldn't find an object to return! );
}
return result;
}
@@ -836,11 +836,11 @@
removed = false;
}
}
- if ( log.isDebugEnabled() ) {
+ if ( log.isTraceEnabled() ) {
if ( removed ) {
-log.debug( Pool + this + destroyed object + object + . );
+log.trace( Pool + this + destroyed object + object + . );
} else {
-log.debug( Pool + this + returned object + object + to the
pool. );
+log.trace( Pool + this + returned object + object + to the
pool. );
}
}
if ( blocking ) {
@@ -910,7 +910,8 @@
}
void runCleanupandShrink() {
- log.debug(running gc for pool);
+ if( log.isTraceEnabled() )
+ log.trace(running gc for pool);
if ( isCleanupEnabled() ) {
// Garbage collection - return any object that's been out too long with no
use
Iterator it = new HashSet( objects.values() ).iterator();
@@ -1004,7 +1005,7 @@
*/
private Object createNewObject( Object parameters, boolean forImmediateUse ) {
Object ob = null;
- boolean debugEnabled = log.isDebugEnabled();
+ boolean traceEnabled = log.isTraceEnabled();
// Serialize creating new objects
synchronized ( resizeLock ) {
// Don't let 2 threads add at the same time
@@ -1023,24 +1024,24 @@
if ( result instanceof PooledObject ) {
( ( PooledObject )result ).addPoolEventListener( this );
}
- if ( debugEnabled ) {
- log.debug( Pool + poolName + gave out new object: +
result );
+ if ( traceEnabled ) {
+ log.trace( Pool + poolName + gave out new object: +
result );
}
ob = result;
} else {
- if ( debugEnabled ) {
- log.debug( Pool + poolName + created a new object: + ob
);
+ if ( traceEnabled ) {
+ log.trace( Pool + poolName + created a new object: + ob
);
}
}
objects = newMap;
} else {
- if ( debugEnabled ) {
- log.debug( Pool + poolName + factory + factory + unable
to create new object! );
+ if ( traceEnabled ) {
+ log.trace( Pool +
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil UILClientILService.java
User: dmaplesden
Date: 01/12/13 16:22:30
Modified:src/main/org/jboss/mq/il/uil UILClientILService.java
Log:
debug - trace logging
Revision ChangesPath
1.5 +4 -3 jbossmq/src/main/org/jboss/mq/il/uil/UILClientILService.java
Index: UILClientILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/UILClientILService.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- UILClientILService.java 2001/09/27 04:09:36 1.4
+++ UILClientILService.java 2001/12/14 00:22:30 1.5
@@ -29,13 +29,13 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
* @created August 16, 2001
*/
public class UILClientILService implements Runnable, org.jboss.mq.il.ClientILService
{
- static org.apache.log4j.Category cat =
org.apache.log4j.Category.getInstance(UILClientILService.class);
+ static org.jboss.logging.Logger cat =
org.jboss.logging.Logger.getLogger(UILClientILService.class);
// Attributes
final static int m_close = 2;
final static int m_deleteTemporaryDestination = 1;
@@ -112,7 +112,8 @@
try
{
-cat.debug(Waiting for a messgage from the server);
+if( cat.isTraceEnabled() )
+ cat.trace(Waiting for a messgage from the server);
code = in.readByte();
}
catch (java.io.InterruptedIOException e)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors Selector.java
User: dmaplesden
Date: 01/12/12 19:28:24
Modified:src/main/org/jboss/mq/selectors Selector.java
Log:
remove overly verbose logging
Revision ChangesPath
1.6 +5 -5 jbossmq/src/main/org/jboss/mq/selectors/Selector.java
Index: Selector.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Selector.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Selector.java 2001/10/28 04:07:35 1.5
+++ Selector.java 2001/12/13 03:28:24 1.6
@@ -24,7 +24,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @author [EMAIL PROTECTED]
* @createdAugust 16, 2001
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class Selector
{
@@ -103,10 +103,10 @@
if (find == null)
{
- if (cat.isDebugEnabled())
- {
- cat.debug(Warning : missing property + id.name);
- }
+ //if (cat.isDebugEnabled())
+ //{
+ // cat.debug(Warning : missing property + id.name);
+ //}
id.value = null;
}
else
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Bugs, mostly: Server stops delivering messsages.
OK so I have never been able to work out exactly how people get assigned to bugs that have been reported. There is a note on the sourceforge bug tracker page about assigning yourself to bugs you are going to fix to avoid duplicated effort. This is clearly a good idea, I just don't know how to do it. Also how do you change the status of a bug report (to close it etc). Maybe I don't have the required permissions do these things? I'm not sure if any special permissions are required. Anyway, Hiram, the point of my above question is that I am pretty sure I know what the problem is for the recently reported bug #491613 that has been assigned to you, do you want me to fix it? Or just let you know what I think the problem is. David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyConnectionConsumer.java
User: dmaplesden
Date: 01/12/11 14:21:49
Modified:src/main/org/jboss/mq Tag: Branch_2_4
SpyConnectionConsumer.java
Log:
Fixed bug #491613, server stops delivering messages
Revision ChangesPath
No revision
No revision
1.5.2.2 +5 -5 jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java
Index: SpyConnectionConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- SpyConnectionConsumer.java2001/08/23 03:57:08 1.5.2.1
+++ SpyConnectionConsumer.java2001/12/11 22:21:49 1.5.2.2
@@ -19,7 +19,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.5.2.1 $
+ * @version$Revision: 1.5.2.2 $
*/
public class SpyConnectionConsumer implements javax.jms.ConnectionConsumer,
SpyConsumer, Runnable {
@@ -148,9 +148,9 @@
while ( true ) {
//get Message
while ( mes == null ) {
- mes = connection.receive( subscription, 0 );
- if ( mes == null ) {
- synchronized ( queue ) {
+ synchronized ( queue ) {
+ mes = connection.receive( subscription, 0 );
+ if ( mes == null ) {
waitingForMessage = true;
while ( queue.isEmpty() !closed ) {
try {
@@ -171,7 +171,7 @@
SpySession spySession = ( SpySession )serverSession.getSession();
if ( spySession.sessionConsumer == null ) {
- cat.debug( + this + Session did not have a set MessageListner
);
+ cat.debug( + this + Session did not have a set MessageListener
);
} else {
spySession.sessionConsumer.subscription = subscription;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bugs, mostly: Server stops delivering messsages.
Anyway, Hiram, the point of my above question is that I am pretty sure I know what the problem is for the recently reported bug #491613 that has been assigned to you, do you want me to fix it? Or just let you know what I think the problem is. If you know whats broke, fix it ;-) OK, done :-) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server MessageCache.java
User: dmaplesden
Date: 01/12/11 19:24:58
Modified:src/main/org/jboss/mq/server MessageCache.java
Log:
Undo my object pooling code, it causes a number of bugs when server is under high
load.
Revision ChangesPath
1.9 +4 -28 jbossmq/src/main/org/jboss/mq/server/MessageCache.java
Index: MessageCache.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageCache.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- MessageCache.java 2001/12/09 05:50:31 1.8
+++ MessageCache.java 2001/12/12 03:24:58 1.9
@@ -24,14 +24,10 @@
* later.
*
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
- * @version$Revision: 1.8 $
+ * @version$Revision: 1.9 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
- //pool of message ref objects
- public static final int MAX_POOL_SIZE = 100*1000;
- protected ArrayList pool = new ArrayList(MAX_POOL_SIZE);
-
// The cached messages are orded in a LRU linked list
private LinkedList lruCache = new LinkedList();
@@ -61,25 +57,6 @@
return this;
}
- //this method is only called from within synchronized block, so don't need to
sync
- protected MessageReference getMessageReference(MessageCache messageCache, Long
referenceId, SpyMessage message) {
- MessageReference ref = null;
- if(!pool.isEmpty())
- ref = (MessageReference)pool.remove(pool.size()-1);
- else
- ref = new MessageReference();
- ref.init(messageCache,referenceId,message);
- return ref;
- }
-
- //this method is only called from within synchronized block, so don't need to
sync
- protected void releaseMessageReference(MessageReference ref){
- if(pool.size() MAX_POOL_SIZE){
- ref.reset();
- pool.add(ref);
- }
- }
-
/**
* Adds a message to the cache
*/
@@ -88,7 +65,8 @@
log.trace(add lock aquire);
synchronized (this)
{
- MessageReference mh = getMessageReference(this, new
Long(messageCounter++), message);
+ MessageReference mh = new MessageReference();
+ mh.init(this, new Long(messageCounter++), message);
lruCache.addLast(mh);
totalCacheSize++;
validateSoftReferenceDepth();
@@ -108,7 +86,6 @@
{
mr.clear();
lruCache.remove(mr);
- releaseMessageReference(mr);
totalCacheSize--;
log.trace(remove lock release);
}
@@ -443,5 +420,4 @@
public void setCacheStore(ObjectName cacheStore) {
cacheStoreObjectName = cacheStore;
}
-
-}
+ }
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
Nope, AutoDeployer behavior definately changed. I put an mbean right after the autodeployer declaration in jboss-service.xml and that mbean gets executed at the same time as the autodeployer is deploying things. That mbean does not wait until the AutoDeployer has finished deploying everything. I know marc is trying to kill off this thread (it has been going long enough) but I know what the story is with this one so I thought I would explain (and give you a solution). The AutoDeployer hasn't really changed much at all, but I made one significant change a while back which is causing this behaviour. Originally all of the services the AutoDeployer uses to do the actual deployment of files (like Jetty or J2eeDeployer) had to be started before the AutoDeployer was started, but since we wanted to make shift services like Jetty into their own SAR files I had to change the AutoDeployer code so that the individual deployment services it uses can be started after it is started. Clearly if you want to deploy Jetty via the AutoDeployer, the AutoDeployer has to be started first! This means that when the AutoDeployer starts it does not have the ability to deploy all the files it finds in the deployment directory (i.e. it cannot deploy ejbs if the J2eeDeployer is not started or wars if Jetty/tomcat is not started) so these files are left until after the appropriate service is started. However if you change your base jboss-service.xml file so that Jetty etc are started before the AutoDeployer is started then it will behave as it always has done. This means of course you can no longer have Jetty etc in seperate SARS, unless someone can figure out how to get the AutoDeployer to deploy the AutoDeployer from a SAR ;-) David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
Good question that is something I am still thinking about here is my current understanding (disclaimer: research). SARs are nice from a packaging standpoint, (i.e. you ship a SAR to a client he can just drop it in his server at run time) but a nightmare from a jar creation/xml file editing standpoint. My favorite way to do this, and what I have been saying from the VERY BEGINNING, (do a search on the early SAR propositions) is let's put the plain xml file with either 1- the classes in lib/ext (we could hot deploy and monitor lib/ext actually) 2- a plain URL that references a file on the system or on a webserver, so you would just put the XML file and say classpath codebase=file:/myclassesinbulk/. This wasn't in David J's stuff originally I just added support for it recently. So just to clarify currently you can use... to add directory (so class files and resources in directory are accessible) classpath codebase=directoryURL / to add specific jars in directory classpath codebase=directoryURL archives=jar1.jar,jar2.zip / to add all jars in directory classpath codebase=directoryURL archives=* / I HAD BUILD THAT SUPPORT IN THE FIRST VERSION ON RH I will make sure it is still there (I think it is actually). Then the *preferred* way is to just drop the xml snippet or add it to the base jboss-service.xml if you know it is going to be part of the server always. The only advantage of doing the snippet would be monitoring and reconfiguring the service based on this. Could be useful. It is for development, which is why I put it back in. David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Depends tag in xml
I added it, it lasted a couple of weeks, David J removed it when he overhauled the entire deployment mechanism. As I didn't have the time to contribute much myself I just left him to it. Use the biggest baddest blow torch you can. Cheers David David M and David J still working with the Spaghetti code in ServiceDeployer, I remember in september we had a depends discussion in *MBEAN* dependency, and DavidM added that to the codebase, I also see a entry in the log from DavidM. now, I can't find anything about the MBean service dependency in the code anymore but this opaque structure of classweneed and classesweprovide and I am veryconfused all of the sudden. question, david m, did you code mbean dependency? was it removed? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Depends tag in xml
For what its worth I think the jar dependency tracking stuff is the only stuff in need of a rethink, the mbean-ref and classpath syntax I am quite happy with. I certainly don't think we need a return to the depends tag. BTW, I have also noticed a bug in the mbean-ref stuff, it would be nice if someone could find and fix it in their journeys. If you have an mbean with a number of mbean refs in it and hot undeploy and hot redeploy the mbean while the server is running, something in the dependency tracking seems to go haywire because when you shut the server down your mbean is then undeployed once for each mbean ref it contains i.e. it is undeployed multiple times. If you haven't hot undeployed and redeployed then this doesn't happen. David he he... in fact 2 problems one real one fake the fake: 'depends' removal i have been working on my codebase for the past 3weeks and the code was update by david j last week :) I was missing it but I did update the server deployer hence panic...my bad the real: the classpath explicit thingy, I think the davidM idea of wildcards is important and I really can't fathom why we are tracking *jars* ... weird. please explain I might be missing it the real2: the over the board service.xml I think we got that covered. marcf --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Problems with MDB in RH
The first error seems to be a class cast exception from your MDB code because the message the bean is receiving is not an ObjectMessage and you try to cast it to one. You need to check whatever is sending messages to the bean is sending ObjectMessages. The other errors look like they occur because it can't find the JAF classes (usually from a jar called activation.jar). You might need to include this activation.jar in the classpath for your beans or add it to the classpath element in your main jboss-service.xml file (the jar is still in lib/ext, it just doesn't get loaded unless you add it to the classpath element). Cheers David. -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 12:26 PM To: JBoss Dev Subject: [JBoss-dev] Problems with MDB in RH I just tried using an MDB that I've used under 2.x without trouble but it didn't work under RH... If anyone has any ideas why this would stop working, please let me know... I'm getting these exceptions: 15:19:17,138 INFO [OILClientIL] ConnectionReceiverOILClient is connecting to: 192.168.1.29:49322 15:19:17,433 INFO [StdServerSession] running (pool, session, xaSession, useLocalTX): , org.jboss.mq.SpyTopicSession@5da0fd, org.jboss.mq.SpyTopicSession@5da0fd, true 15:19:17,759 INFO [StdServerSession] running (pool, session, xaSession, useLocalTX): , org.jboss.mq.SpyTopicSession@b4013, org.jboss.mq.SpyTopicSession@b4013, true 15:19:18,095 ERROR [Default] java.lang.ClassCastException: org.jboss.mq.SpyMessage 15:19:18,097 ERROR [Default]at com.guerrillabroadcasting.groundswell.ejb.mdb.EmailBean.sendEm ail(EmailBean. java:51) 15:19:18,123 ERROR [Default]at com.guerrillabroadcasting.groundswell.ejb.mdb.EmailBean.onMess age(EmailBean. java:41) 15:19:18,125 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 15:19:18,128 ERROR [Default]at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invo ke(MessageDriv enContainer.java:406) 15:19:18,130 ERROR [Default]at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Abstrac tTxInterceptor .java:96) 15:19:18,133 ERROR [Default]at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(Abst ractTxIntercep torBMT.java:142) 15:19:18,166 ERROR [Default]at org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT.invoke(Mes sageDrivenTxIn terceptorBMT.java:36) 15:19:18,174 ERROR [Default]at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke( MessageDrivenI nstanceInterceptor.java:79) 15:19:18,176 ERROR [Default]at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInter ceptor.java:12 7) 15:19:18,179 ERROR [Default]at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 15:19:18,181 ERROR [Default]at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenConta iner.java:281) 15:19:18,184 ERROR [Default]at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContai nerInvoker.jav a:560) 15:19:18,187 ERROR [Default]at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerI mpl.onMessage( JMSContainerInvoker.java:905) 15:19:18,189 ERROR [Default]at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage( SpyMessageCons umer.java:433) 15:19:18,192 ERROR [Default]at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer. java:303) 15:19:18,194 ERROR [Default]at org.jboss.mq.SpySession.run(SpySession.java:216) 15:19:18,197 ERROR [Default]at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:209) 15:19:18,200 ERROR [Default]at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Poo ledExecutor.ja va:642) 15:19:18,202 ERROR [Default]at java.lang.Thread.run(Thread.java:496) 15:19:18,414 WARN [LogInterceptor] Unexpected Error java.lang.NoClassDefFoundError: javax/activation/DataSource at com.guerrillabroadcasting.groundswell.ejb.mdb.EmailBean.sendEm ail(EmailBean. java:75) at com.guerrillabroadcasting.groundswell.ejb.mdb.EmailBean.onMess age(EmailBean. java:41) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invo ke(MessageDriv enContainer.java:406) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Abstrac tTxInterceptor .java:96) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(Abst ractTxIntercep torBMT.java:142) at org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT.invoke(Mes sageDrivenTxIn terceptorBMT.java:36) at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke( MessageDrivenI nstanceInterceptor.java:79) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInter ceptor.java:12 7) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at
RE: [JBoss-dev] RH: running SARs unpacked ? and other questions...
I committed a change to ServiceDeployer a couple of days ago that means you can now add a directory to the classpath of a deployment (does that make sense) as well as jars. This means you should be able to simply extract your sar into a directory of your choosing, edit the jboss-service.xml file so that it contains classpath ... / elements for your directory and the jars in that directory you want to be able to access, and then simply copy the *service.xml file to the deploy directory and everything should work (should meaning I haven't tried this exactly but I can't think of any reason it won't work). Is this what you mean by running unpacked? I do something similar and find it works very well, it means I have all my resources in one directory and after I make a change to them I simply redeploy the *service.xml file and the new changes take effect. Cheers David. PS:syntax to add directory classpath codebase=directoryURL / to add specific jars in directory classpath codebase=directoryURL archives=jar1.jar,jar2.zip / to add all jars in directory classpath codebase=directoryURL archives=* / -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 1:58 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RH: running SARs unpacked ? and other questions... Can a sar be run unpacked - I had the impression this was not so. It would be nicely consistant if I could unpack my SAR and rebuild into the dir hierarchy, touching the descriptor (jboss-service.xml) when I was ready to undeploy/redeploy ? Whilst we are on the subject of SARs, would it also be more consistant to put the descriptors into a separate dir as in META-INF, WEB-INF - only I don't know what it should be called - so forget it ! Lastly - assume that I am writing a service (Jetty) which wants to use EJBs as part of it's implementation. Access to these EJBs needs to be local and optimised. Does this mean that they need to be deployed in the same ClassLoader as Jetty ? I guess I am asking if we can have EARs within SARs ? - or am I not ? Maybe Local interfaces will solve the problem, but I would rather use optimised Remote interfaces, as then I preserve the possibility of deploying several Jetty instances, all talking to a single remote EJB server. I don't see why an optimised Remote interface call should be any slower than an optimised Local interface call, within the same ClassLoader - but then I only do eyes!. Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NPE when using DefaultDS
Ok, I have done some investigation into this and I think I am understanding the problem, I'm just not too sure of the best solution. I would appreciate the opinion of someone who has worked with this code before. The problem is that when a statement obtained from a given jdbc connection throws a SQL exception the connection (through a rather convoluted series of method calls) is being closed. If the client program then tries to create another statement using the same connection a null pointer exception results because the underlying connection is returning a null, having been closed already. Whether this (the connection returning null instead of throwing another SQL excpetion, which is what you would expect from a closed connection) is what should happen or not is kinda beside the point, it is what is happening, and it is happening because our resource and pooling code decides to destroy the connection when a statement from the connection throws an error. So I guess my question is why do we do this? Is there some convention with jdbc I am unaware of that suggests a connection should become unusuable after a statement obtained from that connection throws an error? Or is there some other good reason we are doing this? If so I can change the code so that any attempted use of the connection in this situation will result in a SQL exception rather than a NPE. If there is no particular reason we are doing this then I will (try) to change the code so we don't do this! Guidence from someone who is familiar with this code would be appreciated, else I am going to bang on by myself and can't guarantee the results :-) Thanks David. -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 12:40 PM To: David Maplesden; JBossDev (E-mail) Subject: Re: [JBoss-dev] NPE when using DefaultDS While pooking around i found and : Uncommented body of deleteObject(pooledObject) - line 71 of org/jboss/resource/connectionmanager.ManagedConnectionPoolFactory.java (it seems this is called when the pool shrinks or is shut down. some test -is shrinking the pool to [0/0/10] and as a effect the next test using the DefaultDS do not have a connection ? ... it should probably create one before trying to create a table ? ...) *** Now when running run-testsuite I have 169 tests running and 1 error 99.41% Success rate - heh ... So the xa test is failing above - We knew that - and disabeling it should render a cool 100% of the 169 tests ! ... /peter_f on 1-11-26 22.54, David Maplesden at [EMAIL PROTECTED] wrote: I have been experiencing a NPE when calling createStatement on a connection obtained from DefaultDS. java.lang.NullPointerException at org.jboss.resource.adapter.jdbc.local.StatementInPool.init(S tatementInPool .java:35) at org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createS tatement(Conne ctionInPool.java:606) This doesn't always occur and I have only noticed it in the last week or so, previously it worked fine. It occurs after a previous statement throws an SQLException. In other words if you are using the connections from DefaultDS everything is fine until one of your SQL queries causes an SQL exception. After this point you get a NPE every time you try to create another statement from a connection for DefaultDS. I think (though I don't know for sure) that it has been caused by a change to the Object pool code made last week sometime. I hope someone out there can help. Thanks David. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ 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 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NPE when using DefaultDS
Yes, it was Doug's change that allowed the bug to surface, but on the face of it Doug's change seems a valid one to me, when a managed connection is being deleted from a pool the underlying connection should be closed. I think Doug's change is just showing up some bad handling of the situation that was going unnoticed previously. The problem is being caused by the fact that when the underlying connection is closed the client still has a reference to the connection wrapper, and calling createStatement on this results in a null pointer exception rather than an SQL exception. Of course the other question I was looking for an answer to is why is the connection being closed when a statement throws an exception? Does it need to be? I think there are two things here to fix. David. -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 10:41 AM To: JBossDev (E-mail) Subject: Re: [JBoss-dev] NPE when using DefaultDS The destroy logic was just changed by thedug, so the validity of the changes needs to be justified. I would suggest backing out the change since it seemed to be an unthinking merge from a 2.4 change that may have no relevance to the 3.0 codebase. There were two changes to jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedC onnectionPoolF actory.java This needs to be rolled back to version 1.2 to undo the changes. - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 12:57 PM Subject: RE: [JBoss-dev] NPE when using DefaultDS Ok, I have done some investigation into this and I think I am understanding the problem, I'm just not too sure of the best solution. I would appreciate the opinion of someone who has worked with this code before. The problem is that when a statement obtained from a given jdbc connection throws a SQL exception the connection (through a rather convoluted series of method calls) is being closed. If the client program then tries to create another statement using the same connection a null pointer exception results because the underlying connection is returning a null, having been closed already. Whether this (the connection returning null instead of throwing another SQL excpetion, which is what you would expect from a closed connection) is what should happen or not is kinda beside the point, it is what is happening, and it is happening because our resource and pooling code decides to destroy the connection when a statement from the connection throws an error. So I guess my question is why do we do this? Is there some convention with jdbc I am unaware of that suggests a connection should become unusuable after a statement obtained from that connection throws an error? Or is there some other good reason we are doing this? If so I can change the code so that any attempted use of the connection in this situation will result in a SQL exception rather than a NPE. If there is no particular reason we are doing this then I will (try) to change the code so we don't do this! Guidence from someone who is familiar with this code would be appreciated, else I am going to bang on by myself and can't guarantee the results :-) Thanks David. -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 12:40 PM To: David Maplesden; JBossDev (E-mail) Subject: Re: [JBoss-dev] NPE when using DefaultDS While pooking around i found and : Uncommented body of deleteObject(pooledObject) - line 71 of org/jboss/resource/connectionmanager.ManagedConnectionPoolFactory.java (it seems this is called when the pool shrinks or is shut down. some test -is shrinking the pool to [0/0/10] and as a effect the next test using the DefaultDS do not have a connection ? ... it should probably create one before trying to create a table ? ...) *** Now when running run-testsuite I have 169 tests running and 1 error 99.41% Success rate - heh ... So the xa test is failing above - We knew that - and disabeling it should render a cool 100% of the 169 tests ! ... /peter_f on 1-11-26 22.54, David Maplesden at [EMAIL PROTECTED] wrote: I have been experiencing a NPE when calling createStatement on a connection obtained from DefaultDS. java.lang.NullPointerException at org.jboss.resource.adapter.jdbc.local.StatementInPool.init(S tatementInPool .java:35) at org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createS tatement(Conne ctionInPool.java:606) This doesn't always occur and I have only noticed it in the last week or so, previously it worked fine. It occurs after a previous statement throws
RE: [JBoss-dev] NPE when using DefaultDS
I don't know if you do have to distinguish between fatal and non-fatal errors though. If the error was fatal then the next time the underlying connection is accessed then it will indicate this by throwing a SQL exception of its own. I guess this is not ideal as you want to avoid returning a bad connection to the pool, but we have no indication that the connection is bad, simply because a statement threw an exception. I think we wait until a connection throws an exception of its own before we declare it as bad. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 10:57 AM To: David Maplesden Cc: JBossDev Subject: Re: [JBoss-dev] NPE when using DefaultDS You probably now know more about this is implemented than anyone else at the moment ;-). I haven't looked at this for a while but I think the following is more or less accurate. The problem IMHO is deciding when a fatal error has occured. When it has, the ConnectionManager is supposed to call ManagedConnection.destroy and remove the ManagedConnection from the pool. I think perhaps Doug's recent changes had something to do with this: when the connection dies, you definitely want to ditch the ManagedConnection. However, if you just try to execute some invalid sql, everything is still fine. I haven't looked into sorting SQLExceptions lately. Is there a reasonable way to distinguish fatal from non-fatal exceptions? david jencks On 2001.11.29 15:57:37 -0500 David Maplesden wrote: Ok, I have done some investigation into this and I think I am understanding the problem, I'm just not too sure of the best solution. I would appreciate the opinion of someone who has worked with this code before. The problem is that when a statement obtained from a given jdbc connection throws a SQL exception the connection (through a rather convoluted series of method calls) is being closed. If the client program then tries to create another statement using the same connection a null pointer exception results because the underlying connection is returning a null, having been closed already. Whether this (the connection returning null instead of throwing another SQL excpetion, which is what you would expect from a closed connection) is what should happen or not is kinda beside the point, it is what is happening, and it is happening because our resource and pooling code decides to destroy the connection when a statement from the connection throws an error. So I guess my question is why do we do this? Is there some convention with jdbc I am unaware of that suggests a connection should become unusuable after a statement obtained from that connection throws an error? Or is there some other good reason we are doing this? If so I can change the code so that any attempted use of the connection in this situation will result in a SQL exception rather than a NPE. If there is no particular reason we are doing this then I will (try) to change the code so we don't do this! Guidence from someone who is familiar with this code would be appreciated, else I am going to bang on by myself and can't guarantee the results :-) Thanks David. -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 12:40 PM To: David Maplesden; JBossDev (E-mail) Subject: Re: [JBoss-dev] NPE when using DefaultDS While pooking around i found and : Uncommented body of deleteObject(pooledObject) - line 71 of org/jboss/resource/connectionmanager.ManagedConnectionPoolFactory.java (it seems this is called when the pool shrinks or is shut down. some test -is shrinking the pool to [0/0/10] and as a effect the next test using the DefaultDS do not have a connection ? ... it should probably create one before trying to create a table ? ...) *** Now when running run-testsuite I have 169 tests running and 1 error 99.41% Success rate - heh ... So the xa test is failing above - We knew that - and disabeling it should render a cool 100% of the 169 tests ! ... /peter_f on 1-11-26 22.54, David Maplesden at [EMAIL PROTECTED] wrote: I have been experiencing a NPE when calling createStatement on a connection obtained from DefaultDS. java.lang.NullPointerException at org.jboss.resource.adapter.jdbc.local.StatementInPool.init(S tatementInPool .java:35) at org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createS tatement(Conne ctionInPool.java:606) This doesn't always occur and I have only noticed it in the last week or so, previously it worked fine. It occurs after a previous statement throws an SQLException. In other words if you
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/adapter/jdbc/local StatementInPool.java JDBCManagedConnection.java
User: dmaplesden
Date: 01/11/29 18:34:29
Modified:src/main/org/jboss/resource/adapter/jdbc/local
StatementInPool.java JDBCManagedConnection.java
Log:
My punt at fixing our jdbc connection problems. I have done two things...
1) added a listener to shutdown the ConnectionInPool object(s) when the
managed connection goes to an error state.
2) prevented statement errors being propagated to the connection. The
connection will only go to an error state if its actual underlying connection
throws an exception.
Revision ChangesPath
1.2 +7 -4
jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/StatementInPool.java
Index: StatementInPool.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/StatementInPool.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StatementInPool.java 2001/09/08 19:32:20 1.1
+++ StatementInPool.java 2001/11/30 02:34:28 1.2
@@ -56,10 +56,13 @@
*/
public void setError(SQLException e)
{
- if (con != null)
- {
- con.setError(e);
- }
+ // At this stage I don't think we want to put the connection into an error
state
+ // just because the statement has thrown an error.
+
+ //if (con != null)
+ //{
+ // con.setError(e);
+ //}
}
/**
1.2 +36 -1
jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/JDBCManagedConnection.java
Index: JDBCManagedConnection.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/JDBCManagedConnection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JDBCManagedConnection.java2001/09/08 19:32:20 1.1
+++ JDBCManagedConnection.java2001/11/30 02:34:28 1.2
@@ -28,7 +28,7 @@
*
* @authorAaron Mulder [EMAIL PROTECTED]
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class JDBCManagedConnection extends BaseManagedConnection
{
@@ -102,6 +102,41 @@
*/
public void objectUsed(PoolEvent evt)
{
+}
+ });
+ this.addConnectionEventListener(
+ new javax.resource.spi.ConnectionEventListener()
+ {
+//public void enlist()
+// throws SystemException, RollbackException
+//{
+//}
+
+//public void register()
+// throws SystemException, RollbackException
+//{
+//}
+
+public void localTransactionStarted(ConnectionEvent evt)
+{
+}
+
+public void localTransactionCommitted(ConnectionEvent evt)
+{
+}
+
+public void localTransactionRolledback(ConnectionEvent evt)
+{
+}
+
+public void connectionErrorOccurred(javax.resource.spi.ConnectionEvent
evt)
+{
+ wrapper.shutdown();
+}
+
+public void connectionClosed(javax.resource.spi.ConnectionEvent evt)
+{
+ //no shutdown needed because managed conn is only closed after all
wrappers are closed.
}
});
return wrapper;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NPE when using DefaultDS
I got an improvement in the testsuite as well, but not quite that good. I guess we still have platform differences. David -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 4:51 PM To: David Maplesden Cc: JBossDev Subject: Re: [JBoss-dev] NPE when using DefaultDS With David's fix - I just run-testsuite : result 182 tests with 1 error (XA) Thanks /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment ServiceDeployer.java
User: dmaplesden
Date: 01/11/26 11:47:19
Modified:src/main/org/jboss/deployment ServiceDeployer.java
Log:
Slight change to allow directories to be added to the classpath as well as jars and
zips
Revision ChangesPath
1.16 +144 -118 jboss/src/main/org/jboss/deployment/ServiceDeployer.java
Index: ServiceDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/ServiceDeployer.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ServiceDeployer.java 2001/11/24 19:46:42 1.15
+++ ServiceDeployer.java 2001/11/26 19:47:19 1.16
@@ -49,17 +49,17 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];David Maplesden/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.15 $ p
+ * @version $Revision: 1.16 $ p
*
* b20010830 marc fleury:/b
* ulinitial import
*li
* /ul
- *
+ *
* pb20010905 david maplesden:/b
* ul
- * liChanged deployment procedure to deploy all listed mbeans, then
- * initialise them all before finally starting them all. Changed services
+ * liChanged deployment procedure to deploy all listed mbeans, then
+ * initialise them all before finally starting them all. Changed services
* sets to lists to maintain ordering.
* /ul
*
@@ -70,7 +70,7 @@
*deploy. Made undeploy work, and implemented sar dependency management
*and recursive deploy/undeploy.
* /ol
- *
+ *
* pb20010907 david maplesden:/b
* ul
* liAdded support for depends tag
@@ -136,15 +136,15 @@
/**
* Deploys a package identified by a url string. This stops if a previous
-* version exists. The package can be a *service.xml file, a sar service
+* version exists. The package can be a *service.xml file, a sar service
* archive, or a plain jar or zip file with no deployment descriptor.
-* In any case, all classes found in the package or sar subpackages are
-* added to the extensible classloader. If there are classpath elements
-* in the configuration file, the named packages are loaded
-* (in separate classloaders) unless they have been explicitly undeployed,
+* In any case, all classes found in the package or sar subpackages are
+* added to the extensible classloader. If there are classpath elements
+* in the configuration file, the named packages are loaded
+* (in separate classloaders) unless they have been explicitly undeployed,
* in which case deployment of this package is suspended until they have been
-* redeployed. Then the mbeans named in the configuration file are created
-* using the ServiceController. Dependencies between mbeans are handled by
+* redeployed. Then the mbeans named in the configuration file are created
+* using the ServiceController. Dependencies between mbeans are handled by
* the ServiceController.
*
* @param urlString The location of the package to deploy
@@ -164,23 +164,23 @@
return sdi;
}
- if (sdi.state == EMPTY || sdi.state == GHOST)
+ if (sdi.state == EMPTY || sdi.state == GHOST)
{
- deployLocalClasses(url, null, true);
+ deployLocalClasses(url, null, true);
//Let others waiting on our classes finish deploying.
resolveSuspensions(url, sdi);
} // end of if ()
-
+
if(sdi.dd != null){
boolean suspended = deployNeededPackages(url, sdi);
//Copy local directory if local-directory element is present
- try
+ try
{
NodeList lds = sdi.dd.getElementsByTagName(local-directory);
log.debug(about to copy + lds.getLength() + local directories);
-for (int i = 0; i lds.getLength(); i++)
+for (int i = 0; i lds.getLength(); i++)
{
Element ld = (Element)lds.item(i);
String path = ld.getAttribute(path);
@@ -194,14 +194,14 @@
inflateJar(localUrl, localBaseDir, path);
} // end of for ()
-
+
- } catch (Exception e)
+ } catch (Exception e)
{
log.error(Problem copying local directory, e);
} // end of try-catch
//if we are suspended, we must wait till all classes are available.
- if (!suspended)
+ if (!suspended)
{
addMBeans(url, sdi);
} // end of if ()
@@ -210,104 +210,114 @@
return sdi
[JBoss-dev] Slight change to classpath tag.
I have slightly changed the classpath tag stuff (in *service.xml files) so that directories can be added to the classpath as well as jars and zips. This change will not affect 90% of the classpath tags that are out there. The change is that if you specify a classpath with no archives attribute like.. classpath codebase=file:/... / the directory (or URL) specified will be added to the classpath. Previously this same tag resulted in all jars or zips in the specified directory being added to the classpath. To do this you now have to specify an archives attribute of * i.e. classpath codebase=file:/... archives=* / I found this change quite useful as it allows me to have config files for an mbean in a directory instead of in a jar, much easier to make simple changes and then redeploy the *service.xml file. Cheers David. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment DeployerMBeanSupport.java
User: dmaplesden
Date: 01/11/26 12:10:03
Modified:src/main/org/jboss/deployment DeployerMBeanSupport.java
Log:
This should fix that .zip problem.
Revision ChangesPath
1.13 +45 -45jboss/src/main/org/jboss/deployment/DeployerMBeanSupport.java
Index: DeployerMBeanSupport.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/deployment/DeployerMBeanSupport.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- DeployerMBeanSupport.java 2001/11/26 03:17:47 1.12
+++ DeployerMBeanSupport.java 2001/11/26 20:10:02 1.13
@@ -35,7 +35,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Toby Allsopp/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*
* pbRevisions:/b
*
@@ -65,9 +65,9 @@
* The directory that will contain local copies of deployed packages
*/
private File deployDir;
-
+
// Static
-
+
private static int nextNum = 0;
private static synchronized String generateUniqueDirName()
@@ -80,8 +80,8 @@
public DeployerMBeanSupport()
{
}
+
-
// Public
// DeployerMBean implementation --
@@ -140,12 +140,12 @@
return deployments.containsKey(u);
}
}
-
+
// ServiceMBeanSupport overrides -
-
+
/**
* The codestartService/code method sets up a temporary directory
- * to hold the copies of deployed packages and possibly inflations
+ * to hold the copies of deployed packages and possibly inflations
* of those copies. The format is
(jboss.system.home)/tmp/deploy/(deployername).
*
* @exception Exception if an error occurs
@@ -181,7 +181,7 @@
}
/**
- * The codestopService/code method tries to remove the
+ * The codestopService/code method tries to remove the
* directory created in the initService method.
*
*/
@@ -197,7 +197,7 @@
}
// Package protected -
-
+
// Protected -
/**
@@ -261,18 +261,18 @@
}
-// Below here are helper methods to deal with copying packages,
+// Below here are helper methods to deal with copying packages,
// unpacking packages recursively, finding things in packages,
// and similar tasks needed for most deployment activities.
//
/**
* The codeinflateJar/code copies the jar entries
* from the jar url jarUrl to the directory destDir.
- * It can be used on the whole jar, a directory, or
+ * It can be used on the whole jar, a directory, or
* a specific file in the jar.
*
* @param jarUrl the codeURL/code if the directory or entry to copy.
- * @param destDir the codeFile/code value of the directory in which to
+ * @param destDir the codeFile/code value of the directory in which to
* place the inflated copies.
* @exception DeploymentException if an error occurs
* @exception IOException if an error occurs
@@ -304,12 +304,12 @@
{
JarEntry entry = (JarEntry)e.nextElement();
String name = entry.getName();
-if (path == null || name.startsWith(path))
+if (path == null || name.startsWith(path))
{
File outFile = new File(destDir, name);
- if (!outFile.exists())
+ if (!outFile.exists())
{
-
+
if (entry.isDirectory())
{
outFile.mkdirs();
@@ -334,10 +334,10 @@
in.close();
}
}
-
+
} // end of if (outFile.exists())
} // end of if (matches path)
-
+
}
}
finally
@@ -349,24 +349,24 @@
protected void extractPackages(URL url, DeploymentInfo di)
throws DeploymentException, IOException
{
- if (url.getFile().endsWith(.xml))
+ if (url.getFile().endsWith(.xml))
{
di.addXmlUrl(url);
return;
}
-
- //if its a jar or war, add to list and stop
- if (url.getFile().endsWith(.jar) || url.getFile().endsWith(.war))
+
+ //if its a zip, jar or war, add to list and stop
+ if (url.getFile().endsWith(.zip) || url.getFile().endsWith(.jar) ||
[JBoss-dev] NPE when using DefaultDS
I have been experiencing a NPE when calling createStatement on a connection obtained from DefaultDS. java.lang.NullPointerException at org.jboss.resource.adapter.jdbc.local.StatementInPool.init(StatementInPool .java:35) at org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createStatement(Conne ctionInPool.java:606) This doesn't always occur and I have only noticed it in the last week or so, previously it worked fine. It occurs after a previous statement throws an SQLException. In other words if you are using the connections from DefaultDS everything is fine until one of your SQL queries causes an SQL exception. After this point you get a NPE every time you try to create another statement from a connection for DefaultDS. I think (though I don't know for sure) that it has been caused by a change to the Object pool code made last week sometime. I hope someone out there can help. Thanks David. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyXAResourceManager.java SpyMessage.java MessagePool.java
User: dmaplesden
Date: 01/11/26 15:13:32
Modified:src/main/org/jboss/mq SpyXAResourceManager.java
SpyMessage.java MessagePool.java
Log:
fix a bug caused by my message pooling changes.
Revision ChangesPath
1.5 +1 -11 jbossmq/src/main/org/jboss/mq/SpyXAResourceManager.java
Index: SpyXAResourceManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyXAResourceManager.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpyXAResourceManager.java 2001/11/14 01:53:40 1.4
+++ SpyXAResourceManager.java 2001/11/26 23:13:32 1.5
@@ -20,7 +20,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class SpyXAResourceManager implements java.io.Serializable {
@@ -96,11 +96,6 @@
transaction.acks = job;
}
connection.send( transaction );
- //release messages back to pool now they are sent
- if(transaction.messages != null){
-for(int i=0;itransaction.messages.length;i++)
- MessagePool.releaseMessage(transaction.messages[i]);
- }
} else {
if ( state.txState != TX_PREPARED ) {
throw new XAException( The transaction had not been prepared );
@@ -109,11 +104,6 @@
transaction.xid = xid;
transaction.requestType = transaction.TWO_PHASE_COMMIT_COMMIT_REQUEST;
connection.send( transaction );
- //release messages back to pool now they are sent
- if(transaction.messages != null){
-for(int i=0;itransaction.messages.length;i++)
- MessagePool.releaseMessage(transaction.messages[i]);
- }
}
state.txState = TX_COMMITED;
}
1.11 +3 -3 jbossmq/src/main/org/jboss/mq/SpyMessage.java
Index: SpyMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessage.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- SpyMessage.java 2001/11/14 01:53:40 1.10
+++ SpyMessage.java 2001/11/26 23:13:32 1.11
@@ -25,7 +25,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
*
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.11 $
*/
public class SpyMessage implements Serializable, Message, Comparable,
Externalizable {
@@ -176,7 +176,7 @@
public void setJMSPriority(int priority) throws JMSException {
if (priority 0 || priority 10)
- throw new JMSException(Unsupported priority: priority must be from 0-10);
+ throw new JMSException(Unsupported priority '+priority+': priority must
be from 0-10);
header.jmsPriority = priority;
}
@@ -745,7 +745,7 @@
}
//clear for next use in pool
- void reset() throws JMSException{
+ void clearMessage() throws JMSException{
clearBody();
this.ack = null;
this.session = null;
1.2 +1 -1 jbossmq/src/main/org/jboss/mq/MessagePool.java
Index: MessagePool.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/MessagePool.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MessagePool.java 2001/11/14 01:53:39 1.1
+++ MessagePool.java 2001/11/26 23:13:32 1.2
@@ -130,7 +130,7 @@
if(message == null)
return;
try{
-message.reset();
+message.clearMessage();
}catch(javax.jms.JMSException e){
//unable to re-use message
return;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deployment question (classpath)
Hi All, well Hi David Jencks mostly I guess ;-), With the new deployment system I have started deploying my application by simply deploying the *service.xml file and including all the jars it uses in a classpath / element. This works very well, I can easily keep all my jars together in a lib directory and the *service.xml file is easily available for editing and redeploying. There is one draw back though. I have several *.properties files used by my service that need to also be added to the classpath. Currently the only way I can find to do this is by putting them in one of the jars, however I would like to be able to simply place them in my lib directory (which is specified by my codebase attribute of the classpath element) so that I can edit them and then redeploy the *service.xml to have the changes take effect. I think that in general the ability to add directories to the classpath as well as jars would be very useful to developers. Currently if a classpath element is specified with a codebase attribute but no archives attribute the directory specified by the codebase is searched for jars which are added to the classpath, I would prefer it if the directory itself were simply added. So my questions are: 1) Is there a way to add a simple directory to the classpath of a service? 2) If not, is there a good reason why not? 3) If there is no good reason why not then how difficult do you think this would be to add? 4) Would you have time to do it, or do you want me to have a hack at it? Thanks David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged SpyTxLog.java
User: dmaplesden
Date: 01/11/19 12:41:19
Modified:src/main/org/jboss/mq/pm/rollinglogged SpyTxLog.java
Log:
fixing my bad formatting
Revision ChangesPath
1.6 +100 -100 jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyTxLog.java
Index: SpyTxLog.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyTxLog.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- SpyTxLog.java 2001/11/19 04:06:04 1.5
+++ SpyTxLog.java 2001/11/19 20:41:19 1.6
@@ -18,107 +18,107 @@
*
* @createdAugust 16, 2001
* @author:Hiram Chirino ([EMAIL PROTECTED])
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class SpyTxLog {
- /
- // Attributes
- /
- private IntegrityLog transactionLog;
- private int liveTransactionCount = 0;
- private Object counterLock = new Object();
-
- /
- // Constructors
- /
- SpyTxLog( File file )
- throws JMSException {
- try {
- transactionLog = new IntegrityLog( file );
- } catch ( IOException e ) {
- throwJMSException( Could not open the queue's
tranaction log: + file.getAbsolutePath(), e );
- }
- System.out.println(created SpyTxLog: + this);
- //new Exception().printStackTrace();
- }
-
- /
- // Public Methods
- /
- public synchronized void close()
- throws JMSException {
- try {
- transactionLog.close();
- } catch ( IOException e ) {
- throwJMSException( Could not close the queue's
tranaction log., e );
- }
- }
-
- public synchronized void delete()
- throws JMSException {
- try {
- transactionLog.delete();
- } catch ( IOException e ) {
- throwJMSException( Could not delete the queue's
tranaction log., e );
- }
- }
-
-
- public void createTx()
- throws JMSException {
- synchronized ( counterLock ) {
- ++liveTransactionCount;
- }
- }
-
- public boolean completed()
- throws JMSException {
- synchronized ( counterLock ) {
- return ( liveTransactionCount == 0 );
- }
- }
-
-
- public synchronized void restore( java.util.TreeSet result )
- throws JMSException {
- try {
- result.addAll( transactionLog.toTreeSet() );
- } catch ( Exception e ) {
- throwJMSException( Could not restore the transaction
log., e );
- }
- }
-
- public synchronized void commitTx( org.jboss.mq.pm.Tx id )
- throws JMSException {
-
- try {
- transactionLog.addTx( id );
- transactionLog.commit();
- synchronized ( counterLock ) {
- --liveTransactionCount;
- }
- } catch ( IOException e ) {
- throwJMSException( Could not create a new
transaction., e );
- }
-
- }
-
- public void rollbackTx( org.jboss.mq.pm.Tx txId )
- throws JMSException {
- synchronized ( counterLock ) {
- --liveTransactionCount;
- }
- }
-
-
- /
- // Private Methods
- /
- private void throwJMSException( String message, Exception e )
- throws JMSException {
- JMSException newE = new
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged SpyTxLog.java
User: dmaplesden
Date: 01/11/18 20:06:04
Modified:src/main/org/jboss/mq/pm/rollinglogged SpyTxLog.java
Log:
Remove debugging line (you don't need it anymore David J?)
Revision ChangesPath
1.5 +100 -100 jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyTxLog.java
Index: SpyTxLog.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyTxLog.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpyTxLog.java 2001/11/10 21:38:05 1.4
+++ SpyTxLog.java 2001/11/19 04:06:04 1.5
@@ -18,107 +18,107 @@
*
* @createdAugust 16, 2001
* @author:Hiram Chirino ([EMAIL PROTECTED])
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class SpyTxLog {
- /
- // Attributes
- /
- private IntegrityLog transactionLog;
- private int liveTransactionCount = 0;
- private Object counterLock = new Object();
-
- /
- // Constructors
- /
- SpyTxLog( File file )
- throws JMSException {
- try {
- transactionLog = new IntegrityLog( file );
- } catch ( IOException e ) {
- throwJMSException( Could not open the queue's tranaction log: +
file.getAbsolutePath(), e );
- }
- System.out.println(created SpyTxLog: + this);
- new Exception().printStackTrace();
- }
-
- /
- // Public Methods
- /
- public synchronized void close()
- throws JMSException {
- try {
- transactionLog.close();
- } catch ( IOException e ) {
- throwJMSException( Could not close the queue's tranaction log., e );
- }
- }
-
- public synchronized void delete()
- throws JMSException {
- try {
- transactionLog.delete();
- } catch ( IOException e ) {
- throwJMSException( Could not delete the queue's tranaction log., e );
- }
- }
-
-
- public void createTx()
- throws JMSException {
- synchronized ( counterLock ) {
- ++liveTransactionCount;
- }
- }
-
- public boolean completed()
- throws JMSException {
- synchronized ( counterLock ) {
- return ( liveTransactionCount == 0 );
- }
- }
-
-
- public synchronized void restore( java.util.TreeSet result )
- throws JMSException {
- try {
- result.addAll( transactionLog.toTreeSet() );
- } catch ( Exception e ) {
- throwJMSException( Could not restore the transaction log., e );
- }
- }
-
- public synchronized void commitTx( org.jboss.mq.pm.Tx id )
- throws JMSException {
-
- try {
- transactionLog.addTx( id );
- transactionLog.commit();
- synchronized ( counterLock ) {
---liveTransactionCount;
- }
- } catch ( IOException e ) {
- throwJMSException( Could not create a new transaction., e );
- }
-
- }
-
- public void rollbackTx( org.jboss.mq.pm.Tx txId )
- throws JMSException {
- synchronized ( counterLock ) {
- --liveTransactionCount;
- }
- }
-
-
- /
- // Private Methods
- /
- private void throwJMSException( String message, Exception e )
- throws JMSException {
- JMSException newE = new SpyJMSException( message );
- newE.setLinkedException( e );
- throw newE;
- }
+ /
+ // Attributes
+ /
+ private IntegrityLog transactionLog;
+ private int liveTransactionCount = 0;
+ private Object counterLock = new Object();
+
+ /
+ // Constructors
+ /
+ SpyTxLog( File file )
+ throws JMSException {
+ try {
+ transactionLog = new IntegrityLog( file );
+ } catch ( IOException e ) {
+ throwJMSException( Could not open the queue's
tranaction log:
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
Looks good Hiram,
Can I make one suggestion. When I was profiling and improving JBossMQ's
performance I implemented a couple of static methods
SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of the
standard writeObject and readObject methods. I think you should use them
here.
They work fine, you get back exactly the same object you write out, and they
are used by all the persistence and communication mechanisms currently
because they are many times quicker than the standard object serialization
(which is horribly slow).
Oh, and if we are talking about performance, I would appreciate everyone
being very careful about placing debug statements inside any code that is
executed for every message through the system. Several of these have been
introduced with the advent of the message caching and David J's new stuff.
The cost of constructing all the message strings, even if they aren't used,
can add considerable overhead to the system (if you don't believe me then
create a test and see). Remember I managed to get somewhere between a 10 to
20 times speed improvement by improving the serialisation code and removing
these debug statements from inside the inner loop. If you really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag set to false the
compiler removes the line completely, so there is no performance hit at all.
Thanks David.
-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 5:24 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
CacheStore.java CacheStoreMBean.java
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
for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly
restoring the message
after a server restart.
Revision ChangesPath
1.1
jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
Index: CacheStore.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm.file;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import javax.jms.JMSException;
import org.jboss.mq.SpyJMSException;
import org.jboss.mq.SpyMessage;
import org.jboss.mq.server.MessageReference;
import org.jboss.system.ServiceMBeanSupport;
/**
* This class manages the persistence needs of the MessageCache
*
* @author Hiram Chirino
* @version$Revision: 1.1 $
*/
public class CacheStore extends ServiceMBeanSupport
implements org.jboss.mq.pm.CacheStore, CacheStoreMBean {
String dataDirectory;
File dataFile;
/**
* @see ServiceMBeanSupport#getName()
*/
public String getName() {
return JBossMQ-CacheStore;
}
/**
* @see CacheStore#loadFromStorage(MessageReference)
*/
public SpyMessage loadFromStorage(MessageReference mh)
throws JMSException {
try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectInputStream is = new ObjectInputStream(new
BufferedInputStream(new FileInputStream(f)));
Object rc = is.readObject();
is.close();
return (SpyMessage) rc;
} catch (ClassNotFoundException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
} catch (IOException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
}
}
/**
* @see CacheStore#saveToStorage(MessageReference, SpyMessage)
*/
public void saveToStorage(MessageReference mh,
SpyMessage message) throws JMSException {
try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectOutputStream os = new ObjectOutputStream(new
BufferedOutputStream(new FileOutputStream(f)));
os.writeObject(message);
os.close();
} catch (IOException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
}
}
/**
* @see
RE: [JBoss-dev] RH: tools.jar (javac)...
yeah sounds good, add it if you can find it, if you can't print a warning and carry on -Original Message- From: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 8:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RH: tools.jar (javac)... How about removing the code and leaving a comment in the run.bat file? It's easy to modify the required of JAVA_HOME to add tools.jar if JAVA_HOME is available -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Maplesden Enviado el: miércoles, 14 de noviembre de 2001 19:38 Para: [EMAIL PROTECTED] Asunto: RE: [JBoss-dev] RH: tools.jar (javac)... You might be jumping the gun a bit with this one. tools.jar is only needed afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages. Not everyone will want this, indeed many people will probably run JBoss without a servlet engine, and so they won't need tools.jar. David -Original Message- From: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 7:57 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RH: tools.jar (javac)... I'm preparing a patch (my humble contribution, snif!) for run.bat/run.jar. It includes: 1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME environment variable that points to your java instalation directory. It checks if tools.jar is where it should. If not, it doesn't let you start JBoss. 2.- Moves all the JAXP env variables into run.jar, cleaning the bat file. 3.- Document into run.bat a bit what's happening. 4.- Include commented lines to start jboss in debug mode (JPDA), both by socket and by shared memory. There are docs out there about how to connect to an already started app. I use this one a lot. Ignacio. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas Schaefer Enviado el: miércoles, 14 de noviembre de 2001 16:46 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: [JBoss-dev] RH: tools.jar (javac)... Yes, you are missing the fact that tools.jar is plattform/vendor dependant. Therefore you would have to distribute one for each plattform. Andy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:14 AM Subject: Re: [JBoss-dev] RH: tools.jar (javac)... Maybe I am missing something, but isn't this whole issue about distributing a compiler with JBoss so the user doesn't have to download the JDK and edit a configuration file to point to it? If that is the case, can't we distribute jikes? -Phil Scott M Stark [EMAIL PROTECTED] To: JBossDev \(E-mail\) Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: eforge.net Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 11/13/2001 05:37 PM Please respond to Scott M Stark 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't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... 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 distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
Thanks, that's good to know. The amount and level of logging in JBossMQ
needs to be looked at, its not completely hopeless, but its far from
consistent (mainly because of my changes I guess).
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 15, 2001 9:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update:
jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
This is the purpose of the Logger.isXXXEnabled() call. Any debugging
that is executed on a per message basis should be a trace
level message
that is enclosed inside of a test for that priority level
being active. This
allows for enabling tracing with very fine control at runtime
and one of
the primary reasons for basing logging on log4j. This incurs a minimal
overhead. The current Logger class is a subclass of the log4j Category
and this will be changed next week, but that will not change the usage
pattern which is as follows:
import org.jboss.logging.Logger;
public abstract class SomeClass
{
protected Logger log = Logger.create(Some.class or
whatever category
name);
protected void register(EntityEnterpriseContext ctx,
Transaction tx)
{
boolean trace = log.isTraceEnabled();
if( trace )
log.trace(register, ctx=+ctx+, tx=+tx);
}
}
The cost of constructing all the message strings, even if
they aren't
used,
can add considerable overhead to the system (if you don't
believe me then
create a test and see). Remember I managed to get
somewhere between a 10
to
20 times speed improvement by improving the serialisation code and
removing
these debug statements from inside the inner loop. If you
really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag
set to false the
compiler removes the line completely, so there is no
performance hit at
all.
Thanks David.
___
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
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
I haven't removed any debug statements since I did my initial big contribution some months ago, I thought people might be using them trying to track down a particular bug. Now that we are so close to 3.0 coming out I thought I would mention it in passing so people where aware of the performance hit they impose, of course all we need to do is change them from log.debug() to if(log.isTraceEnabled()) log.trace() and we should be fine. The critical parts of the code are the areas that get executed for every message under normal conditions, anything to do with the basic send, receive, commit methods + the corresponding areas of the various PM's and now the message cache. I don't think many of the changes you have made recently have really been in these areas so you are probably fine. One off things like the restore method and initialisation stuff we can log as much as we like. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 10:30 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java Oops, did you remove the excess debug statements I put in or can you point a bit to where they might be? I'm not at all sure I could recognize such places.. David Jencks On 2001.11.14 14:56:29 -0500 David Maplesden wrote: Looks good Hiram, Can I make one suggestion. When I was profiling and improving JBossMQ's performance I implemented a couple of static methods SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of the standard writeObject and readObject methods. I think you should use them here. They work fine, you get back exactly the same object you write out, and they are used by all the persistence and communication mechanisms currently because they are many times quicker than the standard object serialization (which is horribly slow). Oh, and if we are talking about performance, I would appreciate everyone being very careful about placing debug statements inside any code that is executed for every message through the system. Several of these have been introduced with the advent of the message caching and David J's new stuff. The cost of constructing all the message strings, even if they aren't used, can add considerable overhead to the system (if you don't believe me then create a test and see). Remember I managed to get somewhere between a 10 to 20 times speed improvement by improving the serialisation code and removing these debug statements from inside the inner loop. If you really, really want them then place them behind a static final boolean flag i.e. if(DEBUG) log.debug(a message); so that we can easily set the flag to false and recompile a higher performance version of the engine. With the static flag set to false the compiler removes the line completely, so there is no performance hit at all. Thanks David. -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 5:24 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java 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 for saving and loading messages. Also fixed a small bug in the file PM. It was not properly restoring the message after a server restart. Revision ChangesPath 1.1 jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java Index: CacheStore.java === /* * JBoss, the OpenSource J2EE webOS * * Distributable under LGPL license. * See terms of license at gnu.org. */ package org.jboss.mq.pm.file; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import javax.jms.JMSException; import org.jboss.mq.SpyJMSException; import org.jboss.mq.SpyMessage; import org.jboss.mq.server.MessageReference; import org.jboss.system.ServiceMBeanSupport; /** * This class manages the persistence needs of the MessageCache * * @author Hiram Chirino * @version$Revision: 1.1 $ */ public class CacheStore extends
RE: [JBoss-dev] RH: tools.jar (javac)...
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 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, given the ClassLoader architecture of RH - how should I get hold of tools.jar Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ 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] Message object pools for MQ
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. My early tests indicate a reasonable performance improvement (most noticeable with non-persistent messaging where you don't have the PM overhead). I don't think the changes will break anything anyone else is currently doing so barring any strenuous objections I will finish testing and commit later today. Cheers David. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Message object pools for MQ
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 PROTECTED]] Sent: Wednesday, November 14, 2001 11:27 AM To: JBossDev (E-mail) Subject: [JBoss-dev] Message object pools for MQ 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. My early tests indicate a reasonable performance improvement (most noticeable with non-persistent messaging where you don't have the PM overhead). I don't think the changes will break anything anyone else is currently doing so barring any strenuous objections I will finish testing and commit later today. Cheers David. ___ 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
RE: [JBoss-dev] RH: tools.jar (javac)...
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 distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 1:02 PM To: David Maplesden; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RH: tools.jar (javac)... 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 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 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, given the ClassLoader architecture of RH - how should I get hold of tools.jar Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server BasicQueue.java MessageCache.java MessageReference.java
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 methods.
Revision ChangesPath
1.9 +5 -3 jbossmq/src/main/org/jboss/mq/server/BasicQueue.java
Index: BasicQueue.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/BasicQueue.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- BasicQueue.java 2001/10/28 04:07:35 1.8
+++ BasicQueue.java 2001/11/14 01:53:40 1.9
@@ -31,7 +31,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.8 $
+ * @version$Revision: 1.9 $
*/
//abstract public class BasicQueue implements Runnable {
public class BasicQueue {
@@ -211,7 +211,7 @@
restoreMessage(message);
}
}
-
+
class RemoveMessageTask implements Runnable {
MessageReference message;
RemoveMessageTask(MessageReference m) {
@@ -220,6 +220,8 @@
public void run() {
try {
server.getMessageCache().remove(message);
+ //we are finally done with message so we can release it back to pool
+ org.jboss.mq.MessagePool.releaseMessage(message.hardReference);
} catch ( JMSException e ) {
cat.error(Could not remove an acknowleged message from the
message cache: , e);
}
@@ -257,7 +259,7 @@
Runnable task = new RestoreMessageTask(m, item.subscriberId);
server.getPersistenceManager().getTxManager().addPostRollbackTask(txId,
task);
-
+
task = new RemoveMessageTask(m);
server.getPersistenceManager().getTxManager().addPostCommitTask(txId,
task);
}
1.6 +76 -52jbossmq/src/main/org/jboss/mq/server/MessageCache.java
Index: MessageCache.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageCache.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MessageCache.java 2001/11/12 06:36:49 1.5
+++ MessageCache.java 2001/11/14 01:53:40 1.6
@@ -23,38 +23,61 @@
* later.
*
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
+ //pool of message ref objects
+ public static final int MAX_POOL_SIZE = 100*1000;
+ protected ArrayList pool = new ArrayList(MAX_POOL_SIZE);
+
// The cached messages are orded in a LRU linked list
private LinkedList lruCache = new LinkedList();
-
+
// Provides a Unique ID to MessageHanles
private long messageCounter = 0;
int cacheHits = 0;
int cacheMisses = 0;
-
+
private File dataFile;
private String dataDirectory;
private Thread referenceSoftner;
-
+
private long highMemoryMark = 1024L * 1000 * 16;
private long maxMemoryMark = 1024L * 1000 * 32;
public static final long ONE_MEGABYTE = 1024L * 1000;
-
+
int softRefCacheSize = 0;
int totalCacheSize = 0;
-
+
// Used to get notified when message are being deleted by GC
ReferenceQueue referenceQueue = new ReferenceQueue();
-
+
public MessageCache getInstance()
{
return this;
}
+ //this method is only called from within synchronized block, so don't need to
sync
+ protected MessageReference getMessageReference(MessageCache messageCache, Long
referenceId, SpyMessage message) {
+ MessageReference ref = null;
+ if(!pool.isEmpty())
+ ref = (MessageReference)pool.remove(pool.size()-1);
+ else
+ ref = new MessageReference();
+ ref.init(messageCache,referenceId,message);
+ return ref;
+ }
+
+ //this method is only called from within synchronized block, so don't need to
sync
+ protected void releaseMessageReference(MessageReference ref){
+ if(pool.size() MAX_POOL_SIZE){
+ ref.reset();
+ pool.add(ref);
+ }
+ }
+
/**
* Adds a message to the cache
*/
@@ -63,16 +86,16 @@
log.trace(add lock aquire);
synchronized (this)
{
- MessageReference mh = new MessageReference(this, new
Long(messageCounter++), message);
+ MessageReference mh
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq MessagePool.java SpyBytesMessage.java SpyEncapsulatedMessage.java SpyMapMessage.java SpyMessage.java SpyObjectMessage.java SpyQueueSender.java SpySession.java SpyStreamMessage.java SpyTextMessage.java SpyTopicPublisher.java SpyXAResourceManager.java
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
SpyStreamMessage.java SpyTextMessage.java
SpyTopicPublisher.java SpyXAResourceManager.java
Added: src/main/org/jboss/mq MessagePool.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage methods.
Revision ChangesPath
1.5 +2 -2 jbossmq/src/main/org/jboss/mq/SpyBytesMessage.java
Index: SpyBytesMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyBytesMessage.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpyBytesMessage.java 2001/10/28 04:07:34 1.4
+++ SpyBytesMessage.java 2001/11/14 01:53:39 1.5
@@ -18,7 +18,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class SpyBytesMessage
extends SpyMessage
@@ -402,7 +402,7 @@
public SpyMessage myClone()
throws JMSException {
- SpyBytesMessage result = new SpyBytesMessage();
+ SpyBytesMessage result = MessagePool.getBytesMessage();
this.reset();
result.copyProps( this );
if ( this.InternalArray != null ) {
1.4 +2 -2 jbossmq/src/main/org/jboss/mq/SpyEncapsulatedMessage.java
Index: SpyEncapsulatedMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyEncapsulatedMessage.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpyEncapsulatedMessage.java 2001/10/28 04:07:34 1.3
+++ SpyEncapsulatedMessage.java 2001/11/14 01:53:39 1.4
@@ -15,7 +15,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public class SpyEncapsulatedMessage
extends SpyObjectMessage {
@@ -54,7 +54,7 @@
public SpyMessage myClone()
throws javax.jms.JMSException {
- SpyEncapsulatedMessage result = new SpyEncapsulatedMessage();
+ SpyEncapsulatedMessage result = MessagePool.getEncapsulatedMessage();
result.copyProps( this );
//HACK to get around read only problem
boolean readOnly = result.header.msgReadOnly;
1.4 +2 -2 jbossmq/src/main/org/jboss/mq/SpyMapMessage.java
Index: SpyMapMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMapMessage.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpyMapMessage.java2001/10/28 04:07:34 1.3
+++ SpyMapMessage.java2001/11/14 01:53:39 1.4
@@ -20,7 +20,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public class SpyMapMessage
extends SpyMessage
@@ -373,7 +373,7 @@
public SpyMessage myClone()
throws JMSException {
- SpyMapMessage result = new SpyMapMessage();
+ SpyMapMessage result = MessagePool.getMapMessage();
result.copyProps( this );
result.content = ( Hashtable )this.content.clone();
return result;
1.10 +44 -11jbossmq/src/main/org/jboss/mq/SpyMessage.java
Index: SpyMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessage.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- SpyMessage.java 2001/11/10 21:38:04 1.9
+++ SpyMessage.java 2001/11/14 01:53:40 1.10
@@ -25,7 +25,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
*
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class SpyMessage implements Serializable, Message, Comparable,
Externalizable {
@@ -68,7 +68,7 @@
//For ordering in the JMSServerQueue (set on the server side)
public transient long messageId;
}
-
+
public Header header = new Header();
public transient AcknowledgementRequest ack;
@@ -445,7 +445,7 @@
}
public SpyMessage myClone() throws JMSException {
- SpyMessage
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/jms ClusterTopicSession.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 -9 jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSession.java Index: ClusterTopicSession.java === RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSession.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ClusterTopicSession.java 2001/10/28 04:07:34 1.4 +++ ClusterTopicSession.java 2001/11/14 01:53:40 1.5 @@ -42,7 +42,7 @@ * * @author Hiram Chirino ([EMAIL PROTECTED]) * @createdAugust 16, 2001 - * @version$Revision: 1.4 $ + * @version$Revision: 1.5 $ */ public class ClusterTopicSession implements TopicSession @@ -192,7 +192,7 @@ throw new IllegalStateException( The session is closed ); } - SpyBytesMessage message = new SpyBytesMessage(); + SpyBytesMessage message = org.jboss.mq.MessagePool.getBytesMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -203,7 +203,7 @@ throw new IllegalStateException( The session is closed ); } - SpyMapMessage message = new SpyMapMessage(); + SpyMapMessage message = org.jboss.mq.MessagePool.getMapMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -214,7 +214,7 @@ throw new IllegalStateException( The session is closed ); } - SpyMessage message = new SpyMessage(); + SpyMessage message = org.jboss.mq.MessagePool.getMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -225,7 +225,7 @@ throw new IllegalStateException( The session is closed ); } - SpyObjectMessage message = new SpyObjectMessage(); + SpyObjectMessage message = org.jboss.mq.MessagePool.getObjectMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -236,7 +236,7 @@ throw new IllegalStateException( The session is closed ); } - SpyObjectMessage message = new SpyObjectMessage(); + SpyObjectMessage message = org.jboss.mq.MessagePool.getObjectMessage(); message.setObject( object ); message.header.producerClientId = connection.getClientID(); return message; @@ -248,7 +248,7 @@ throw new IllegalStateException( The session is closed ); } - SpyStreamMessage message = new SpyStreamMessage(); + SpyStreamMessage message = org.jboss.mq.MessagePool.getStreamMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -259,7 +259,7 @@ throw new IllegalStateException( The session is closed ); } - SpyTextMessage message = new SpyTextMessage(); + SpyTextMessage message = org.jboss.mq.MessagePool.getTextMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -270,7 +270,7 @@ throw new IllegalStateException( The session is closed ); } - SpyTextMessage message = new SpyTextMessage(); + SpyTextMessage message = org.jboss.mq.MessagePool.getTextMessage(); message.setText( string ); message.header.producerClientId = connection.getClientID(); return message; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Deployment exception on Clustering
From what I can follow of this conversation I think what Bill needs is a
bunch of mbeans to be initialised before any of them are started i.e.
mbean1.init();
mbean2.init();
mbean3.init();
mbean1.start();
mbean2.start();
mbean3.start();
as opposed to
mbean1.init();
mbean1.start();
mbean2.init();
mbean2.start();
mbean3.init();
mbean3.start();
and as long as he has a way to do this (using postRegister to call init or
whatever) he will be happy.
AFAICS then the questions are
1) Can we do this for him? if yes then great.
2) Is this absolutely neccessary or is there some fancy way he could keep
track of things and work around his problem? if yes then ok (except maybe
for whoever has to implement the fancy bit). I think however the answer to
this may be no because it sounds like the HAPartition has to exist (i.e. be
initialised) first and then have other mbeans register with it before it is
then started, and the other mbeans can't be started until HAPartition is
started, is this correct?
If no to both of the above then we have a problem with David J's new
deployment stuff...
Cheers
David
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 13, 2001 11:48 AM
To: Bill Burke
Cc: Andreas Schaefer; David Jencks; Sacha Labourey;
[EMAIL PROTECTED]
Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
To do this, subclass ServiceMbeanSupport, descend your
classes from this
subclass, and override PostRegister to call your init method, after
super.postRegister:
public void postRegister(Boolean registrationDone)
{
super.postRegister(registrationDone);
if (registrationDone.booleanValue())
{
init();
}
}
you should probably do something similar with preUnregister(?).
IMHO you should not be making any reference to anything
outside the mbean
in init. Even Rickard is viewing init as an internal
configuration step.
In this case, I can't see why you can't put the code at the
beginning of
start. It might be slower (run more often), but will have the
same effect.
I think using explicit mbean references will result in a more
satisfactory
and sturdy solution.
david jencks
On 2001.11.12 17:04:34 -0500 Bill Burke wrote:
Rickard talked about something called postRegister?
-Original Message-
From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 12, 2001 4:50 PM
To: David Jencks
Cc: Sacha Labourey;
[EMAIL PROTECTED]; Bill Burke
Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering
Hi David
You hear it. How can be use init() again for Clustering ?
Andy
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Andreas Schaefer [EMAIL PROTECTED]
Cc: Sacha Labourey [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, November 12, 2001 1:10 PM
Subject: [JBoss-dev] RE: Deployment exception on Clustering
Yes this a very serious problem and it wouldn't show up
with your
Farm
stuff. THis is my fault because I didn't document the code
very well, but
can we please switch this back?
In the init phase, all services register with the cluster
(HAPartition)
for
cluster events that want to listen to and also if they
require state
synchronization. In the start phase, the ClusterPartition
mbean does the
final Connect to the JavaGroups message Channel. When
the Connect
happens,
state synchronization starts. Services will not have
their state
synchronized if everything is done in the start phase.
Bill
-Original Message-
From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 12, 2001 3:50 PM
To: Bill Burke
Cc: Sacha Labourey; [EMAIL PROTECTED]
Subject: Re: Deployment exception on Clustering
Hi Bill
I added all the code from init() into start(). Is
this a problem ?
At least when I use the Farm it works like a charm.
Andy
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: David Jencks [EMAIL PROTECTED];
Andreas Schaefer
[EMAIL PROTECTED]
Cc: Sacha Labourey [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, November 12, 2001 12:59 PM
Subject: RE: Deployment exception on Clustering
Guys,
The clustering stuff is dependent on init and start
both being
there. Can
we put back the init? Otherwise you break our
stuff. Why are
you
doing
this anyways?
Bill
-Original Message-
From: David Jencks
[mailto:[EMAIL PROTECTED]]
Sent: Monday, November 12, 2001 2:33 PM
To: Andreas Schaefer
Cc: David Jencks; Bill Burke; Sacha
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server BasicQueue.java
User: dmaplesden
Date: 01/10/22 13:38:51
Modified:src/main/org/jboss/mq/server Tag: Branch_2_4 BasicQueue.java
Log:
Backport bug fix for race condition to 2.4 branch
Revision ChangesPath
No revision
No revision
1.4.2.2 +30 -27jbossmq/src/main/org/jboss/mq/server/BasicQueue.java
Index: BasicQueue.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/BasicQueue.java,v
retrieving revision 1.4.2.1
retrieving revision 1.4.2.2
diff -u -r1.4.2.1 -r1.4.2.2
--- BasicQueue.java 2001/08/23 03:57:12 1.4.2.1
+++ BasicQueue.java 2001/10/22 20:38:51 1.4.2.2
@@ -30,7 +30,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4.2.1 $
+ * @version$Revision: 1.4.2.2 $
*/
//abstract public class BasicQueue implements Runnable {
public class BasicQueue {
@@ -146,34 +146,37 @@
throws JMSException {
SpyMessage message = null;
Selector selector = sub.getSelector();
- if ( selector == null ) {
- synchronized ( messages ) {
-if ( messages.size() != 0 ) {
- message = ( SpyMessage )messages.first();
- messages.remove( message );
-}
- }
- } else {
- synchronized ( messages ) {
-Iterator i = messages.iterator();
-while ( i.hasNext() ) {
- SpyMessage m = ( SpyMessage )i.next();
- if ( selector.test( m ) ) {
- message = m;
+ synchronized ( receivers ) {
+ if ( selector == null ) {
+synchronized ( messages ) {
+ if ( messages.size() != 0 ) {
+ message = ( SpyMessage )messages.first();
messages.remove( message );
- break;
+ }
+}
+ } else {
+synchronized ( messages ) {
+ Iterator i = messages.iterator();
+ while ( i.hasNext() ) {
+ SpyMessage m = ( SpyMessage )i.next();
+ if ( selector.test( m ) ) {
+ message = m;
+ messages.remove( message );
+ break;
+ }
}
}
}
- }
-
- if ( message == null ) {
- if ( wait ) {
-addToReceivers( sub );
+
+ if ( message == null ) {
+if ( wait ) {
+ addToReceivers( sub );
+}
+ } else {
+setupMessageAcknowledgement( sub, message );
}
- } else {
- setupMessageAcknowledgement( sub, message );
}
+
return message;
}
@@ -331,11 +334,11 @@
}
}
}
- }
- //else add to message list
- synchronized ( messages ) {
- messages.add( message );
+ //else add to message list
+ synchronized ( messages ) {
+messages.add( message );
+ }
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyMessageConsumer.java
User: dmaplesden
Date: 01/10/22 13:39:06
Modified:src/main/org/jboss/mq Tag: Branch_2_4
SpyMessageConsumer.java
Log:
Backport bug fix for race condition to 2.4 branch
Revision ChangesPath
No revision
No revision
1.7.2.2 +21 -19jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.7.2.1
retrieving revision 1.7.2.2
diff -u -r1.7.2.1 -r1.7.2.2
--- SpyMessageConsumer.java 2001/08/23 03:57:08 1.7.2.1
+++ SpyMessageConsumer.java 2001/10/22 20:39:06 1.7.2.2
@@ -25,7 +25,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.7.2.1 $
+ * @version$Revision: 1.7.2.2 $
*/
public class SpyMessageConsumer implements MessageConsumer, SpyConsumer, Runnable {
@@ -129,18 +129,19 @@
receiving = true;
}
- SpyMessage msg = session.connection.receive( subscription, 0 );
- if ( msg != null ) {
- Message mes = preProcessMessage( msg );
- if ( mes != null ) {
-synchronized ( stateLock ) {
- receiving = false;
+ synchronized ( messages ) {
+
+ SpyMessage msg = session.connection.receive( subscription, 0 );
+ if ( msg != null ) {
+Message mes = preProcessMessage( msg );
+if ( mes != null ) {
+ synchronized ( stateLock ) {
+ receiving = false;
+ }
+ return mes;
}
-return mes;
}
- }
- synchronized ( messages ) {
try {
waitingForMessage = true;
while ( true ) {
@@ -190,18 +191,19 @@
long endTime = System.currentTimeMillis() + timeOut;
- SpyMessage msg = session.connection.receive( subscription, timeOut );
- if ( msg != null ) {
- Message mes = preProcessMessage( msg );
- if ( mes != null ) {
-synchronized ( stateLock ) {
- receiving = false;
+ synchronized ( messages ) {
+
+ SpyMessage msg = session.connection.receive( subscription, timeOut );
+ if ( msg != null ) {
+Message mes = preProcessMessage( msg );
+if ( mes != null ) {
+ synchronized ( stateLock ) {
+ receiving = false;
+ }
+ return mes;
}
-return mes;
}
- }
- synchronized ( messages ) {
try {
waitingForMessage = true;
while ( true ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBossMQ STILL hangs
Title: JBossMQ STILL hangs Hi Sheng, This sounds like the same bug I fixed in the HEAD source code last week. From a couple of things you have said (jboss.jcml file??) it sounds like you are running from the jboss 2.4 code, probably the jboss 2.4.3 release. I have only just backported the bug fix to the 2.4 branch so if you want to run a fixed version you will have to wait for the next release or run jboss from the source code. Let me know if you still have a problem and you are running from the latest code. Cheers David. -Original Message-From: Sheng Zou [mailto:[EMAIL PROTECTED]]Sent: Friday, October 19, 2001 4:02 PMTo: 'David Maplesden'; JBossDev (E-mail)Subject: JBossMQ STILL hangs Hi David, With your fix, it proceeds much further but still hangs after running for a while. I have a stress test, which I sucessfully run over 10 million messages against fioranoMQ w/o problem, but it could NOT run over 1 million when running against JBossMQ. I attached the required jars to run the test: Messaging.jar, idul.jar, Utils.jar, and messaging source file (MessagingSRC.zip) for your reference. Also, I attached a batch file to run the test, which you would need to change env variables to run under your environment. Lastly, you need to add two queues, namely, iCC_Alice2Bob_Q and iCC_Bob2Alice_Q to your jboss.jcml file. What the test does is to send nRequest/Reply via nSessions simultanuously! You could run the test as: % runJBossMQStressTest.bat 100 500 where 100 refers to one million request/reply message, and 500 refers to 500 simultanuous requestors. Basically, the test will hang running for a while. Thanks, Sheng BTW, the test are sending Persistent Request/Reply messages using Logged PM. -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 14, 2001 6:50 PM To: JBossDev (E-mail) Subject: FW: [JBoss-dev] QueueRequestor hangs when sending a lot of messag es Forwarding to list, damm reply to still gets me at least once a week... -Original Message- From: David Maplesden Sent: Monday, October 15, 2001 2:43 PM To: 'Jim Hazen' Subject: RE: [JBoss-dev] QueueRequestor hangs when sending a lot of messages Hi Jim, I had a look at your problem using the code you sent. Turns out there was a bug in the concurrency code for SpyMessageConsumer and having the two threads beating up on the same queue showed it up beautifully. I fixed it anyway and things should (hopefully) now run fine, it worked for me for well over 1000 messages. Let us know if you continue to have problems. Cheers, David -Original Message- From: Jim Hazen [mailto:[EMAIL PROTECTED]] Sent: Monday, October 15, 2001 12:46 PM To: jboss-dev Subject: [JBoss-dev] QueueRequestor hangs when sending a lot of messages The is in response to a thread on the JBossMQ forum. Attached are two programs which show the problem I've been having. The replier program simply gets a message and then sends that message on to it's ReplyTo destination. The requestor test, sequentialy sends x messages where x is a command line arg and uses a QueueRequestor to wait and get a response. The programs are simple and non threaded, so I don't see a reason for some messages to go through and others to not. In my tests, I find I can send between 25 and 70 messages without a hang. However set the number to 1000 and things get hung up every time. There is some debug output generated by the programs showing what messages have been sent, recieved and responded to. I hope that this hang can be reproduced by you guys and this problem fixed. I'm running code from the latest cvs HEAD pull as of about 4:30pm PST 9/14/01. Let me know if you need more info. -Jim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: JBossMQ STILL hangs
Title: JBossMQ STILL hangs Ok, just to clear Sheng's good name, there was still a bug (or actually the same bug in a slightly different place) that should (touch wood) now be fixed. -Original Message-From: David Maplesden [mailto:[EMAIL PROTECTED]]Sent: Tuesday, October 23, 2001 9:46 AMTo: JBossDev (E-mail)Subject: [JBoss-dev] RE: JBossMQ STILL hangs Hi Sheng, This sounds like the same bug I fixed in the HEAD source code last week. From a couple of things you have said (jboss.jcml file??) it sounds like you are running from the jboss 2.4 code, probably the jboss 2.4.3 release. I have only just backported the bug fix to the 2.4 branch so if you want to run a fixed version you will have to wait for the next release or run jboss from the source code. Let me know if you still have a problem and you are running from the latest code. Cheers David. -Original Message-From: Sheng Zou [mailto:[EMAIL PROTECTED]]Sent: Friday, October 19, 2001 4:02 PMTo: 'David Maplesden'; JBossDev (E-mail)Subject: JBossMQ STILL hangs Hi David, With your fix, it proceeds much further but still hangs after running for a while. I have a stress test, which I sucessfully run over 10 million messages against fioranoMQ w/o problem, but it could NOT run over 1 million when running against JBossMQ. I attached the required jars to run the test: Messaging.jar, idul.jar, Utils.jar, and messaging source file (MessagingSRC.zip) for your reference. Also, I attached a batch file to run the test, which you would need to change env variables to run under your environment. Lastly, you need to add two queues, namely, iCC_Alice2Bob_Q and iCC_Bob2Alice_Q to your jboss.jcml file. What the test does is to send nRequest/Reply via nSessions simultanuously! You could run the test as: % runJBossMQStressTest.bat 100 500 where 100 refers to one million request/reply message, and 500 refers to 500 simultanuous requestors. Basically, the test will hang running for a while. Thanks, Sheng BTW, the test are sending Persistent Request/Reply messages using Logged PM. -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 14, 2001 6:50 PM To: JBossDev (E-mail) Subject: FW: [JBoss-dev] QueueRequestor hangs when sending a lot of messag es Forwarding to list, damm reply to still gets me at least once a week... -Original Message- From: David Maplesden Sent: Monday, October 15, 2001 2:43 PM To: 'Jim Hazen' Subject: RE: [JBoss-dev] QueueRequestor hangs when sending a lot of messages Hi Jim, I had a look at your problem using the code you sent. Turns out there was a bug in the concurrency code for SpyMessageConsumer and having the two threads beating up on the same queue showed it up beautifully. I fixed it anyway and things should (hopefully) now run fine, it worked for me for well over 1000 messages. Let us know if you continue to have problems. Cheers, David -Original Message- From: Jim Hazen [mailto:[EMAIL PROTECTED]] Sent: Monday, October 15, 2001 12:46 PM To: jboss-dev Subject: [JBoss-dev] QueueRequestor hangs when sending a lot of messages The is in response to a thread on the JBossMQ forum. Attached are two programs which show the problem I've been having. The replier program simply gets a message and then sends that message on to it's ReplyTo destination. The requestor test, sequentialy sends x messages where x is a command line arg and uses a QueueRequestor to wait and get a response. The programs are simple and non threaded, so I don't see a reason for some messages to go through and others to not. In my tests, I find I can send between 25 and 70 messages without a hang. However set the number to 1000 and things get hung up every time. There is some debug output generated by the programs showing what messages have been sent, recieved and responded to. I hope that this hang can be reproduced by you guys and this problem fixed. I'm running code from the latest cvs HEAD pull as of about 4:30pm PST 9/14/01. Let me know if you need more info. -Jim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyTopicPublisher.java
User: dmaplesden Date: 01/10/04 16:25:12 Modified:src/main/org/jboss/mq SpyTopicPublisher.java Log: No need to copy message in publish Revision ChangesPath 1.3 +2 -5 jbossmq/src/main/org/jboss/mq/SpyTopicPublisher.java Index: SpyTopicPublisher.java === RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTopicPublisher.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- SpyTopicPublisher.java2001/08/17 03:04:01 1.2 +++ SpyTopicPublisher.java2001/10/04 23:25:11 1.3 @@ -20,7 +20,7 @@ * @author Norbert Lataille ([EMAIL PROTECTED]) * @author Hiram Chirino ([EMAIL PROTECTED]) * @createdAugust 16, 2001 - * @version$Revision: 1.2 $ + * @version$Revision: 1.3 $ */ public class SpyTopicPublisher extends SpyMessageProducer @@ -99,11 +99,8 @@ message = m; } - //Clone the message so we can make the outbound message read only - SpyMessage clone = ( ( SpyMessage )message ).myClone(); - clone.setReadOnlyMode(); //Send the message - mySession.sendMessage( clone ); + mySession.sendMessage( ( SpyMessage )message ); } } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged PersistenceManager.java
User: dmaplesden
Date: 01/10/04 16:28:28
Modified:src/main/org/jboss/mq/pm/rollinglogged
PersistenceManager.java
Log:
Fix a problem with cleaning up data files.
Revision ChangesPath
1.8 +5 -1
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- PersistenceManager.java 2001/09/10 03:26:44 1.7
+++ PersistenceManager.java 2001/10/04 23:28:28 1.8
@@ -32,7 +32,7 @@
* This class manages all persistence related services.
*
* @author David Maplesden ([EMAIL PROTECTED])
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
org.jboss.mq.pm.PersistenceManager, PersistenceManagerMBean
{
@@ -130,6 +130,10 @@
queues.put(key, dest);
SpyTxLog txLog = null;
+ // if called before we have been started there is no need to setup log files
+ if(currentTxLog == null)
+ return;
+
HashMap logs;
synchronized (messageLogs)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/jvm JVMServerIL.java JVMClientIL.java
User: dmaplesden
Date: 01/10/04 16:26:45
Modified:src/main/org/jboss/mq/il/jvm JVMServerIL.java
JVMClientIL.java
Log:
Fix for a subtle bug. If messages are not copied on delivery to client and client
then modifies the message and does a rollback, the modified message is restored
instead of the original.
Revision ChangesPath
1.4 +6 -2 jbossmq/src/main/org/jboss/mq/il/jvm/JVMServerIL.java
Index: JVMServerIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMServerIL.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JVMServerIL.java 2001/09/26 05:02:28 1.3
+++ JVMServerIL.java 2001/10/04 23:26:45 1.4
@@ -27,7 +27,7 @@
*
* @authorHiram Chirino ([EMAIL PROTECTED])
* @authorNorbert Lataille ([EMAIL PROTECTED])
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
* @created August 16, 2001
*/
public class JVMServerIL implements org.jboss.mq.il.ServerIL
@@ -235,7 +235,11 @@
public SpyMessage receive(ConnectionToken dc, int subscriberId, long wait)
throws Exception
{
- return server.receive(dc, subscriberId, wait);
+ SpyMessage message = server.receive(dc, subscriberId, wait);
+ //copy message to avoid server side problems with persisted message if
message is edited client side.
+ if(message != null)
+ message = message.myClone();
+ return message;
}
/**
1.4 +8 -1 jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientIL.java
Index: JVMClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientIL.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JVMClientIL.java 2001/09/26 05:02:28 1.3
+++ JVMClientIL.java 2001/10/04 23:26:45 1.4
@@ -19,7 +19,7 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
* @created August 16, 2001
*/
public class JVMClientIL implements ClientIL
@@ -80,6 +80,13 @@
{
throw new IllegalStateException(The client IL is stopped);
}
+
+ //copy messages to avoid server side problems when messages are edited client
side.
+ for (int i = 0; i messages.length; i++)
+ {
+ messages[i].message = messages[i].message.myClone();
+ }
+
connection.asynchDeliver(messages);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyDestination.java
User: dmaplesden
Date: 01/10/02 19:27:40
Modified:src/main/org/jboss/mq SpyDestination.java
Log:
Change to externalization code to handle externalising temporary destinations
Revision ChangesPath
1.3 +13 -1 jbossmq/src/main/org/jboss/mq/SpyDestination.java
Index: SpyDestination.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyDestination.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SpyDestination.java 2001/08/17 03:04:01 1.2
+++ SpyDestination.java 2001/10/03 02:27:40 1.3
@@ -18,7 +18,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class SpyDestination
implements Destination, Serializable {
@@ -31,6 +31,8 @@
protected final static int OBJECT = 1;
protected final static int SPY_QUEUE = 2;
protected final static int SPY_TOPIC = 3;
+ protected final static int SPY_TEMP_QUEUE = 4;
+ protected final static int SPY_TEMP_TOPIC = 5;
SpyDestination( String name ) {
this.name = name;
@@ -54,6 +56,12 @@
throws java.io.IOException {
if ( dest == null ) {
out.writeByte( NULL );
+ } else if ( dest instanceof SpyTemporaryQueue ) {
+ out.writeByte( SPY_TEMP_QUEUE );
+ out.writeUTF( ( ( SpyTemporaryQueue )dest ).getName() );
+ } else if ( dest instanceof SpyTemporaryTopic ) {
+ out.writeByte( SPY_TEMP_TOPIC );
+ out.writeUTF( ( ( SpyTemporaryTopic )dest ).getName() );
} else if ( dest instanceof SpyQueue ) {
out.writeByte( SPY_QUEUE );
out.writeUTF( ( ( SpyQueue )dest ).getName() );
@@ -79,6 +87,10 @@
byte destType = in.readByte();
if ( destType == NULL ) {
return null;
+ } else if ( destType == SPY_TEMP_QUEUE ) {
+ return new SpyTemporaryQueue( in.readUTF(), null );
+ } else if ( destType == SPY_TEMP_TOPIC ) {
+ return new SpyTemporaryTopic( in.readUTF(), null );
} else if ( destType == SPY_QUEUE ) {
return new SpyQueue( in.readUTF() );
} else if ( destType == SPY_TOPIC ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyDestination.java
User: dmaplesden
Date: 01/10/02 20:06:51
Modified:src/main/org/jboss/mq Tag: Branch_2_4 SpyDestination.java
Log:
Change to externalization code to handle externalising temporary destinations
Revision ChangesPath
No revision
No revision
1.2.2.2 +13 -1 jbossmq/src/main/org/jboss/mq/SpyDestination.java
Index: SpyDestination.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyDestination.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- SpyDestination.java 2001/08/23 03:57:08 1.2.2.1
+++ SpyDestination.java 2001/10/03 03:06:51 1.2.2.2
@@ -18,7 +18,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
public class SpyDestination
implements Destination, Serializable {
@@ -31,6 +31,8 @@
protected final static int OBJECT = 1;
protected final static int SPY_QUEUE = 2;
protected final static int SPY_TOPIC = 3;
+ protected final static int SPY_TEMP_QUEUE = 4;
+ protected final static int SPY_TEMP_TOPIC = 5;
SpyDestination( String name ) {
this.name = name;
@@ -54,6 +56,12 @@
throws java.io.IOException {
if ( dest == null ) {
out.writeByte( NULL );
+ } else if ( dest instanceof SpyTemporaryQueue ) {
+ out.writeByte( SPY_TEMP_QUEUE );
+ out.writeUTF( ( ( SpyTemporaryQueue )dest ).getName() );
+ } else if ( dest instanceof SpyTemporaryTopic ) {
+ out.writeByte( SPY_TEMP_TOPIC );
+ out.writeUTF( ( ( SpyTemporaryTopic )dest ).getName() );
} else if ( dest instanceof SpyQueue ) {
out.writeByte( SPY_QUEUE );
out.writeUTF( ( ( SpyQueue )dest ).getName() );
@@ -79,6 +87,10 @@
byte destType = in.readByte();
if ( destType == NULL ) {
return null;
+ } else if ( destType == SPY_TEMP_QUEUE ) {
+ return new SpyTemporaryQueue( in.readUTF(), null );
+ } else if ( destType == SPY_TEMP_TOPIC ) {
+ return new SpyTemporaryTopic( in.readUTF(), null );
} else if ( destType == SPY_QUEUE ) {
return new SpyQueue( in.readUTF() );
} else if ( destType == SPY_TOPIC ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] The fix for bug #462253 is not acceptable
Ooops, sounds like I messed up by applying it... Still, lazy hacking, that hurts... I prefer a slight oversight. -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Monday, October 01, 2001 6:34 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] The fix for bug #462253 is not acceptable The fix for bug[ #462253 ] TextMessage fails for 64k content is not acceptable for 3 reasons: 1. It breaks backward compatibility with previous versions but does not change the SpyTextMessage.serialVersionUID value. Using the 2.4.1 jbossmq jars produces the following exceptions when run with the mdb unit test against a server using the latest 2.4 branch jbossmq jars: [OILServerILService] Client request resulted in a server exception: java.lang.NegativeArraySizeException at java.lang.StringBuffer.init(StringBuffer.java:116) at org.jboss.mq.SpyTextMessage.readExternal(SpyTextMessage.java:76) at org.jboss.mq.SpyMessage.readMessage(SpyMessage.java:589) at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:219) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception: java.rmi.RemoteException: Bad method code ! at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService. java:273) at java.lang.Thread.run(Thread.java:484) [OILServerILService] Client request resulted in a server exception:
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server StateManager.java
Ummm, that's just a default value for the file. It gets replaced by
whatever value the user wants in to use in the config file. I could throw
an exception instead of having a default value if you want.
David
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 5:17 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] CVS update:
jbossmq/src/main/org/jboss/mq/server StateManager.java
| private HashSet loggedOnClientIds;
| - private String stateFile = jbossmq-state.xml;
| + private String stateFile = conf/default/jbossmq-state.xml;
David, I think this is a bad idea, you are hardcoding the
configuration of
the files...
think some more about this... use somewhere else to store that file
marcf
|
| /**
| * Constructor for the StateManager object
| @@ -60,7 +60,7 @@
| */
| public void setStateFile(java.lang.String newStateFile)
| {
| - stateFile = newStateFile;
| + stateFile = newStateFile.trim();
| }
|
| /**
| @@ -389,8 +389,16 @@
| */
| public void loadConfig() throws java.io.IOException,
|org.jboss.mq.xml.XElementException
| {
| - java.io.File jbossHome = new
|java.io.File(System.getProperty(jboss.system.home));
| + java.io.File jbossHome = new
|java.io.File(System.getProperty(jboss.system.home));
| + if (!jbossHome.exists())
| + {
| + category.error(jboss.system.configurationDirectory
|not found! : + jbossHome);
| + }
| java.io.File file = new java.io.File(jbossHome, stateFile);
| + if (!file.exists())
| + {
| + category.error(statefile not found! : + file);
| + }
| java.io.InputStream in = new
|java.io.BufferedInputStream(new java.io.FileInputStream(file));
| stateConfig = XElement.createFrom(in);
| in.close();
|
|
|
|
|___
|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-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JSR/SAR (Jetty) Undeployment...
JBossMQ also has a similar requirement, as would a db service. There are a couple of issues (I feel) with service deployment at the moment. How I think it should be done is... 1) Forget about dealing with dependencies in the ServiceDeployer, this should be done by the AutoDeployer because that way we can specify dependencies between all deployable files i.e. between ear's and sar's and jar's and rar's etc. 2) Sars should contain jars, a jboss-service.xml and a directory structure. All of these get expanded somewhere so no reference to the original sar is maintained. This is so the user can then move the sar out of the autodeploy directory again, at the moment you cannot because of file sharing violations. 3) The directory structure thing is kinda curly because some services (like a db) would want the directory structure to be set up the first time it was deployed but NOT over-written on subsequent deployements (because it contains persistent data). Other files, like config files, you would probably want to be copied over to import a new configuration from the sar. That's my two cents, I have been thinking about writing some code and trying it out but I suddenly got real busy at work and haven't had time. Cheers, David -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:57 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JSR/SAR (Jetty) Undeployment... |Hot-deploying the Jetty service works fine. What happened to the idea of creating your own directory layout space upon deployment from the JSR I thought that was very useful... do you still require this? it would be very useful for me to work with a specific case marcf | |Hot-undeploying generates the following exception : | | |[AutoDeployer] Auto undeploy of |file:/mnt/megalodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0 |.0alpha/deploy/jetty-service.xml | |[JettyService] Stopping |[Jetty] Stopped SocketListener on 0.0.0.0:8080 |[JettyService] Stopped |[JettyService] Destroying |[Jetty] Destroy SocketListener on 0.0.0.0:8080 |[Jetty] Deregister Jetty:Jetty=0,SocketListener=0 |[JettyService] Destroyed |[ServiceDeployer] Mbean exception while executing undeploy on |[Ljava.lang.Object;@333a0e |javax.management.InstanceNotFoundException: :service=Jetty | at |com.sun.management.jmx.MBeanServerImpl.unregisterMBean(MBeanServerI |mpl.java:945) | | at |org.jboss.system.ServiceController.undeploy(ServiceController .java:248) | at java.lang.reflect.Method.invoke(Native Method) | at |com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1628) | | at |com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1523) | | at |org.jboss.deployment.ServiceDeployer.invoke(ServiceDeployer.java:949) | at |org.jboss.deployment.ServiceDeployer.undeploy(ServiceDeployer .java:681) | at java.lang.reflect.Method.invoke(Native Method) | at |com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1628) | | at |com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl .java:1523) | | at org.jboss.deployment.AutoDeployer.undeploy(AutoDeployer.java:664) | at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:270) | at java.lang.Thread.run(Thread.java:484) | |It looks like the service was located and successfully shut down and |destroyed. Then something went wrong. | |Is this a known problem in undeployment, or something peculiar to the |Jetty service. | |Perhaps Jetty's own MBeans are confusing the issue - I'll run some |tests... | | |I would like to get it fixed, as it will speed my development cycle |substantially if I can bounce just the Jetty service, and not the whole |server, each time I recompile my stuff. | | |Thanks, Guys, | | | |Jules | | | | |_ |Do You Yahoo!? |Get your free @yahoo.com address at http://mail.yahoo.com | | |___ |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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH, Jetty, Service Archives...
OK, you saw my last email ( in the JSR/SAR (Jetty) Undeployment... thread)
right?
Well then expanding a little, this is what I had envisioned...
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 10:23 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] RH, Jetty, Service Archives...
| 3. Can I include jars in it (I tried top level dir and
META-INF/lib -
| no joy) - how ?
|
|
|You can't currently include jars, you should be able to in
my opinion, but
|currently you can't.
TODO
|Whichever you think is best. I personally think there
should be room for a
|directory structure in a sar that gets expanded when it is
deployed. This
yes TODO
|There would be issues with redeployment but
|they shouldn't be hard to resolve.
Can you expand on how you would solve the redeployment issues
on directory
structures in SARs.
In fact I need the following
1- how would you package it? where?
2- how would you specify it? needed?
3- what happens on redeploy.
1- keep it simple. in a sar you can have a directory called root in the
META-INF dir, everything that is in this directory is copied exactly to
${jboss.system.deployed}\sarname\root
I think we then add a method to ServiceMBeanSupport that looks up this
directory, this way it can be set by the ServiceDeployer if the mbean being
deployed extends ServiceMBeanSupport (or implements the ServiceMBean
interface) and is easy for clients to find.
All the jars in the sar are also copied to ${jboss.system.deployed}\sarname
to avoid the file sharing violations that prevent the user from simply
moving the original file to undeploy. This is under the assumption that all
required classes are now in jars, I guess we can copy plain class files too,
but jars would be neater I reckon.
2- not sure what you mean? the above paragraph maybe.
3- I think (again going for simple) that when the sar is redeployed nothing
from the directory structure is overwritten, but the jars are. This way any
persistent data in the directory structure is kept and any configuration
files the user wants to update manually can be updated in the expanded
directory structure and when the sar is redeployed the new configuration
will take effect. If the user wants the files from the sar to be copied
over all they have to do is delete the ones in the deployed directory before
they redeploy their app.
I think this will pretty much allow us to do we want to do.
As usual when designing features don't go for full design in
the future go
for simple and right now you will be surprised about the
staying power of
simple and right now
This is something I am begining to learn the hard way. *wry grin*
|Cheers
|
|David
David, if you have some time try to pitch in there, if not
let me know I
believe I will try to work on some stuff over the next few
days. I need to
take care of the marketing of JBoss but I want to code some of the rh
advanced features (jmx bus stuff)...
I am away all from work all next week, so I won't be able to do anything and
when I get back chances are I will have a stack of stuff to catch up on etc,
so its not really looking good. I do have time today to look at some simple
stuff. In fact I think I can come up with a simple dependency mechanism for
the AutoDeployer which will clean up a lot of those issues by handling it
all in one place. That will just leave the service deployer changes to do.
If people don't mind leaving it a couple of weeks I might be able to get
back to it.
That's the best I can do at the moment, my priorities have to be keeping on
top of any reported bugs in JBossMQ and our developments at work.
David.
marcf
___
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
RE: [JBoss-dev] Thoughts on deployers
OK, I agree with most of what you propose... with one big difference. I now feel (after already playing with service deployer) that dependencies have no real place in the individual deployers, they just complicate the code for each of them (or for the proposed universal deployer). At the end of the day the only thing which needs to know about ANY dependencies is the AutoDeployer, the individual deployers should just be able to concentrate on deploying the application they are asked to, when they are asked to. The AutoDeployer can keep track of dependencies (including recursive ones if you want) across all types of files and deploy and undeploy the right files at that right times. I think this is much cleaner and will be much easier for people to use, and the dependency stuff won't interfere when users manually deploy/undeploy things via JMX. So the consequences of this are... 1- classpaths go back to being classpaths instead of recursive dependency lists. 2- no dependency stuff in *-service.xml files 3- hence no need for *-service.xml files in jars, ears or rars 4- individual deployers have no need to deploy any other files, they just do their normal jobs. 5- autodeployer keeps track of dependencies, asks individual deployers to deploy and undeploy when neccessary. 6- autodeployer reads the dependencies for the files in given watched directory from a dependencies.xml file in that directory, no file = no dependencies. What do you think? David M -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 1:40 PM To: jboss-dev Subject: [JBoss-dev] Thoughts on deployers Ok, I'm almost ready to get to work ;-) We need to be able to deploy: sar rar ear ejb-jar war plain old jar directories (?) *-service.xml files we need to be able to unpack sar rar ear and put the contained jars in a directory structure and find one or more config files. Any of the *ar packages may contain a *-service.xml file which can contain *ar/*-service.xml dependency information (in one or more classpath elements) (meaning automatically deploy these first, if not already deployed) mbean dependency information (meaning wait till these mbeans are started before creating any mbeans configured in this package) mbean configuration I'll talk about recursive deployment/undeployment and suspension in more detail in another post. A sar can presumably contain any of the other packages, an ear can contain any of the other packages, a rar can contain plain old jars (and other libs) The other packages have sun-specified deployment descriptors also. So, I propose a universal deployer, that has access to unpacking services, can create and aggregate classloaders, and can delegate interpretation of the *.xml configuration files to the appropriate sub-deployers, in a specified order: jboss-service.xml application.xml ra.xml ejb-jar.xml the war config file (don't know much about this one) Many of these delegate deployers may end up calling the universal deployer again to deploy sub-packages, in particular the jboss-service.xml has the classpath dependencies to deploy. The autodeployer just watches for new/timestamp-changed files and calls deploy for the former, undeploy and deploy for the latter. It doesn't need to know about any deployers except the universal deployer. So what I'd like to do first is make the universal deployer and unpacking service, and hook everything else up to it, removing the existing unpacking services from RARDeployer and J2eeDeployer (which maybe we should call EARDeployer). (I think this is essentially what David Maplesden is thinking of also, however I do have time now ;-)) How does this look? thanks 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
RE: [JBoss-dev] Thoughts on deployers
I have absolutely no problem with recursive dependencies, the examples you give illustrate where and why they can be useful. My problem is that simply doing the dependency stuff in ServiceDeployer doesn't solve the whole problem, because the service deployer can't enfore dependencies between the services it is deploying and rar's and ear's etc. For example any ear you want to deploy needs to wait for the jetty-service.xml file to be deployed first, otherwise it has no servlet container to run in. But the ServiceDeployer can't enforce this because it doesn't deploy ear's. However I think the AutoDeployer can enforce these dependencies AND there is no reason why it can't enforce the recursive dependencies you need as well, I just think dealing with dependencies in more than one place is a waste of time and effort. Instead of having every deployer do dependencies in its own way simply let the AutoDeployer take care of them all. I do see the dependencies.xml file exactly as a sort of deployment script, and it would differ from the classpath in a couple of very fundamental ways. 1) it can enforce dependencies between any sorts of files you want to deploy 2) IT IS NOT A CLASSPATH I know doing it this way would result in some duplicated information, because jars would be listed in a classpath element as well as in the dependency info, but I just think it is better. You could even have the autodeployer automatically use the classpath element to build the dependency info, but it is not the only place dependency info can come from. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 3:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Thoughts on deployers Ok, 2 points: Well, I'm not too thrilled with the dependency stuff as it currently works either, but I think something like it is necessary. Here are the things I want to be able to do, that I think lead to recursive deployment and dependencies. a. After I deploy mystuff-service.xml, depending on 47 other packages in its classpath, and containing 150 mbean configurations, I discover that one of the jars, stuff.jar is the wrong version. I want to be able to undeploy stuff.jar, have all the depending packages (including mystuff-service.xml) undeploy and suspend, and redeploy stuff.jar (correct version) and have all the suspended packages redeploy. If there are 27 packages depending on stuff.jar, I don't want to have to figure out what they are and undeploy them by hand so I can fix stuff.jar. To me, this means that the classpath stuff is dependency information. b. If you allow sars containing both a jboss-service.xml and some classes, you get recursive dependencies, and you have to (imho) allow including sars in classpaths. For instance, I want all the jca stuff in one sar, I don't think it makes sense otherwise. You need it all, why make it easy to break by losing one package? However, this means every mydb-service.xml file setting up a ConnectionFactoryLoader needs (for completeness) jbosscx.sar in its classpath... this example doesn't recurse (recur?) too much, but we've opened the door to recursion of indefinite depth. Second... I don't understand why you want the AutoDeployer to know about dependency information, but not the ServiceDeployer. As far as I know, the only dependency info we have now is in *service.xml files, where it is really relevant: classpath and needed mbeans. Why make it harder for someone who wants to deploy programatically? Or do you think of dependencies.xml as sort of a deployment script? How would it be different from the classpath in *service.xml? Anyway.. I think we maybe agree on the universal deployer and the unpacking service? Thanks david jencks On 2001.09.20 21:45:50 -0400 David Maplesden wrote: OK, I agree with most of what you propose... with one big difference. I now feel (after already playing with service deployer) that dependencies have no real place in the individual deployers, they just complicate the code for each of them (or for the proposed universal deployer). At the end of the day the only thing which needs to know about ANY dependencies is the AutoDeployer, the individual deployers should just be able to concentrate on deploying the application they are asked to, when they are asked to. The AutoDeployer can keep track of dependencies (including recursive ones if you want) across all types of files and deploy and undeploy the right files at that right times. I think this is much cleaner and will be much easier for people to use, and the dependency stuff won't interfere when users manually deploy/undeploy things via JMX. So the consequences of this are... 1- classpaths go back to being classpaths instead of recursive dependency lists
RE: [JBoss-dev] RH, Jetty, Service Archives...
It definately happens my Windows 2000 system, I don't know if it happens
under other OS's or not. The basic solution (I believe) is as you say, to
copy the original then open the copy.
David
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 3:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] RH, Jetty, Service Archives...
snip
All the jars in the sar are also copied to
${jboss.system.deployed}\sarname
to avoid the file sharing violations that prevent the user
from simply
moving the original file to undeploy. This is under the
assumption that
all
required classes are now in jars, I guess we can copy plain
class files
too,
but jars would be neater I reckon.
Is this (file sharing violations) some kind of windows-only problem? I
haven't had it yet or I would have fixed it ;-). Is the fix
to copy the
original, then open the copy?
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
RE: [JBoss-dev] Thoughts on deployers
I don't know, I beginning to regret starting to think about it :-) It's hard, there are different pro's and con's to each approach. At the moment the autodeployer thing I have done does not do any recursive deploy/undeploy at all, but I think it would be easy to build in. Scott has a good point as well, but I can't think of any other way of expressing the dependencies for the AutoDeployer as it has absolutely no information about the format of the files it is deploying. You could easily make it so that every file has its own dependency file and you simply drop them both into the deployment directory at the same time. I don't know if this is really any better... David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 3:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Thoughts on deployers Well, I certainly want to see it, I hope my reservations in my reply to your previous post are answered by it. Do you think they are? Thanks david jencks On 2001.09.20 22:37:44 -0400 David Maplesden wrote: OK, (trying to be helpful) I have finished implementing a dependency mechanism in the AutoDeployer. I am going to finish testing it, change the default configuration a little to use it and then commit it so you can have a look before I leave (remember I will be away for the next week or so). Please, please, please do dependencies this way, I really think it is the best approach. It should be easy for you build recursive deploy/undeploy into the AutoDeployer on top of what I have done, and it will make writing the ServiceDeployer miles easier. Also the J2ee deployer and RAR deployer will not need to be changed at all, a bonus in my book. If you have any serious reservations about this let me know now and won't commit, but if you want the code I have written today I think it will be of use. David -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 1:46 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Thoughts on deployers OK, I agree with most of what you propose... with one big difference. I now feel (after already playing with service deployer) that dependencies have no real place in the individual deployers, they just complicate the code for each of them (or for the proposed universal deployer). At the end of the day the only thing which needs to know about ANY dependencies is the AutoDeployer, the individual deployers should just be able to concentrate on deploying the application they are asked to, when they are asked to. The AutoDeployer can keep track of dependencies (including recursive ones if you want) across all types of files and deploy and undeploy the right files at that right times. I think this is much cleaner and will be much easier for people to use, and the dependency stuff won't interfere when users manually deploy/undeploy things via JMX. So the consequences of this are... 1- classpaths go back to being classpaths instead of recursive dependency lists. 2- no dependency stuff in *-service.xml files 3- hence no need for *-service.xml files in jars, ears or rars 4- individual deployers have no need to deploy any other files, they just do their normal jobs. 5- autodeployer keeps track of dependencies, asks individual deployers to deploy and undeploy when neccessary. 6- autodeployer reads the dependencies for the files in given watched directory from a dependencies.xml file in that directory, no file = no dependencies. What do you think? David M -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 1:40 PM To: jboss-dev Subject: [JBoss-dev] Thoughts on deployers Ok, I'm almost ready to get to work ;-) We need to be able to deploy: sar rar ear ejb-jar war plain old jar directories (?) *-service.xml files we need to be able to unpack sar rar ear and put the contained jars in a directory structure and find one or more config files. Any of the *ar packages may contain a *-service.xml file which can contain *ar/*-service.xml dependency information (in one or more classpath elements) (meaning automatically deploy these first, if not already deployed) mbean dependency information (meaning wait till these mbeans are started before creating any mbeans configured in this package) mbean configuration I'll talk about recursive deployment/undeployment and suspension in more detail in another post. A sar can presumably contain any of the other packages
RE: [JBoss-dev] Thoughts on deployers
OK, I've finished the AutoDeployer stuff and it works, but I guess it might not be the whole solution so I've decided not to commit it to CVS. I will send it to you off-list in case you find it useful. You know my thoughts on the whole issue. To clarify I have two main concerns. 1) make dependency specification as easy and consistent as possible across all package types. I guess allowing for the inclusion of a jboss-service.xml (or even a jboss-dependency.xml ??) in every type of package as you suggested would acomplish this. 2) allow the specification of dependencies between packages deployed by different deployers. It is very important that a sar can be made to wait for an ear or a rar or vice versa. The simplest way of doing this is to let the AutoDeployer do it, if you come up with a another way then that's all good too. I have a custom sar that uses the DefaultDS, and if it gets deployed before the jboss-jdbc.rar then it fails so we need to be able to do this. I will be interested to see what you can come up with, good hunting while I'm gone ;-) Cheers David. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 4:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Thoughts on deployers I'm glad you like my examples, I was beginning to worry I was the only one who thought those were worthwhile scenarios. I still don't understand why you want the AutoDeployer to do dependency checking rather than ServiceDeployer/UniversalDeployer. I think manual deployment should have access to the same dependency info as auto deployment-- I regard autodeployment as chiefly a development convenience, I would expect a production site to want more of a script-based audit-trail friendly deployment method. We want to be able to include jboss-service.xml files in an ear anyway, to be able to include mbean configuration specific to the application. Why not use it for dependencies as well? Also, to me, the fact that the dependency list is currently labelled classpath is, well, kind of irrelevant. I think of it as a list of stuff that needs to be deployed in the current scope before the current file is deployed. If there are undeployed classes on it, they go into the current scopes' classloader. If they are a *-service.xml file, they get processed first. It's not like we're checking to make sure that the list is complete-- if you leave out the classpath but all the classes for your mbeans are already available, we don't keep you from creating your mbeans. I sometimes understand your wish you never started thinking about this ;-)). Thanks david jencks On 2001.09.20 23:04:56 -0400 David Maplesden wrote: I have absolutely no problem with recursive dependencies, the examples you give illustrate where and why they can be useful. My problem is that simply doing the dependency stuff in ServiceDeployer doesn't solve the whole problem, because the service deployer can't enfore dependencies between the services it is deploying and rar's and ear's etc. For example any ear you want to deploy needs to wait for the jetty-service.xml file to be deployed first, otherwise it has no servlet container to run in. But the ServiceDeployer can't enforce this because it doesn't deploy ear's. However I think the AutoDeployer can enforce these dependencies AND there is no reason why it can't enforce the recursive dependencies you need as well, I just think dealing with dependencies in more than one place is a waste of time and effort. Instead of having every deployer do dependencies in its own way simply let the AutoDeployer take care of them all. I do see the dependencies.xml file exactly as a sort of deployment script, and it would differ from the classpath in a couple of very fundamental ways. 1) it can enforce dependencies between any sorts of files you want to deploy 2) IT IS NOT A CLASSPATH I know doing it this way would result in some duplicated information, because jars would be listed in a classpath element as well as in the dependency info, but I just think it is better. You could even have the autodeployer automatically use the classpath element to build the dependency info, but it is not the only place dependency info can come from. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 3:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Thoughts on deployers Ok, 2 points: Well, I'm not too thrilled with the dependency stuff as it currently works either, but I think something like it is necessary. Here are the things I want to be able to do, that I think lead to recursive deployment and dependencies. a. After I deploy mystuff-service.xml, depending
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
I'll have a look, I've been through the MQ test stuff before and it did all work originally. I haven't looked at it since all the changes to the build system and new test stuff so its not too surprising if its having trouble. I'll let you know how I get on. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 7:35 AM To: jboss-dev Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) Hi, It appears that most of the jbossmq tests are not working currently with rh. Much of this appears to me to be configuration problems. On my machine, running JBossMQPerfStressTestCase usually freezes something so that subsequent tests don't run and jboss will not shut down: for this reason I commented it out of the testsuite/build.xml. Could the jbossmq experts take a look? You may find the ability to set counts via a local.properties file useful: ### Test properties junit.timeout=12 jbosstest.threadcount=2 jbosstest.iterationcount=2 jbosstest.beancount=2 You may find the one-test target useful: ./build.sh -DJBossMQPerfStressTestCase one-test runs only the named test. Thanks 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
RE: [JBoss-dev] RH, Jetty, Service Archives...
Hi Julian, Most of your problems are coming from the fact that service deployment has only really been half done, there are several issues directly relating to your comments below that need to be sorted out. Briefly then... I am working on packaging up the Jetty service into an archive. I have some questions... 1. Should I call it a SAR or a JSR ? Whichever you want, I think I am begining to prefer .sar 2. should I deploy it to ./deploy or ./deploy/lib ? Probably in ./deploy/lib as this way you are guaranteed that it will be deployed before any EAR's in ./deploy. This is one of the outstanding issues with deployment at the moment, we have no way of specifying dependencies between sar's and ear's and rar's. 3. Can I include jars in it (I tried top level dir and META-INF/lib - no joy) - how ? You can't currently include jars, you should be able to in my opinion, but currently you can't. 4. Should Jetty's configuration be done in the archive, nicely packaged, but awkward to edit, or in ./conf/default, easy to edit but ... - or both ? Whichever you think is best. I personally think there should be room for a directory structure in a sar that gets expanded when it is deployed. This way you can include it in your sar and then it gets expanded to where someone can easily edit it. There would be issues with redeployment but they shouldn't be hard to resolve. 5. It only seems to deploy some of the time - other times I get : java.net.MalformedURLException: no protocol: META-INF/jboss-service.xml at java.net.URL.init(URL.java:473) at java.net.URL.init(URL.java:376) at java.net.URL.init(URL.java:330) at org.jboss.deployment.ServiceDeployer.getDocument(Unknown Source) at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) at org.jboss.deployment.AutoDeployer.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) [AutoDeployer] Deployment failed:file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0 alpha/deploy/lib/jetty.sar org.jboss.deployment.DeploymentException: No valid service.xml file foundno protocol: META-INF/jboss-service.xml at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) at org.jboss.deployment.AutoDeployer.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) This final error should only occur if there is no jboss-service.xml file in the sar's META-INF directory. Let us know if it occurs otherwise. And yet if I restart with the same service deployed - no problemo. Once the exception has been thrown, that seems to be it. Subsequent deployments all fail in the same manner. Any clues/pointers would be much appreciated, Jules Cheers David _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ 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] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/test JBossMQUnitTestCase.java
User: dmaplesden
Date: 01/09/19 15:45:23
Modified:src/main/org/jboss/test/jbossmq/test
JBossMQUnitTestCase.java
Log:
added additional simple tests
Revision ChangesPath
1.3 +221 -10
jbosstest/src/main/org/jboss/test/jbossmq/test/JBossMQUnitTestCase.java
Index: JBossMQUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/test/JBossMQUnitTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JBossMQUnitTestCase.java 2001/09/15 01:50:16 1.2
+++ JBossMQUnitTestCase.java 2001/09/19 22:45:23 1.3
@@ -15,14 +15,14 @@
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-package org.jboss.test.jbossmq.test;
+package org.jboss.test.jbossmq.test;
import javax.naming.*;
import javax.jms.*;
import java.util.*;
-import org.apache.log4j.Category;
import org.jboss.test.JBossTestCase;
+import org.apache.log4j.Category;
/**
* JBossMQUnitTestCase.java
@@ -32,7 +32,7 @@
* @author
* @version
*/
-public class JBossMQUnitTestCase
+public class JBossMQUnitTestCase
extends JBossTestCase
{
// Provider specific
@@ -43,6 +43,7 @@
static String TEST_TOPIC = topic/testTopic;
//JMSProviderAdapter providerAdapter;
+ static Context context;
static QueueConnection queueConnection;
static TopicConnection topicConnection;
@@ -55,7 +56,7 @@
private void drainQueue() throws Exception {
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)getInitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueReceiver receiver = session.createReceiver(queue);
Message message = receiver.receive( 2000 );
@@ -82,10 +83,15 @@
protected void connect() throws Exception {
- QueueConnectionFactory queueFactory = (QueueConnectionFactory)
getInitialContext().lookup(QUEUE_FACTORY);
+ if( context == null ) {
+
+ context = new InitialContext();
+
+ }
+ QueueConnectionFactory queueFactory = (QueueConnectionFactory)
context.lookup(QUEUE_FACTORY);
queueConnection = queueFactory.createQueueConnection();
- TopicConnectionFactory topicFactory =
(TopicConnectionFactory)getInitialContext().lookup(TOPIC_FACTORY);
+ TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.lookup(TOPIC_FACTORY);
topicConnection = topicFactory.createTopicConnection();
getLog().debug(Connection to spyderMQ established.);
@@ -117,7 +123,7 @@
drainQueue();
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)getInitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueSender sender = session.createSender(queue);
TextMessage message = session.createTextMessage();
@@ -173,9 +179,10 @@
public void run() {
Category log = Category.getInstance(getClass().getName());
try {
+
log.debug(Server Thread Started);
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)new InitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueReceiver queueReceiver = session.createReceiver(queue);
@@ -198,7 +205,7 @@
log.debug(Server Thread Finished);
} catch ( Exception e ) {
- log.error(Error, e);
+ log.error(Error,e);
}
}
};
@@ -206,7 +213,7 @@
serverThread.start();
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)getInitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueRequestor queueRequestor = new QueueRequestor(session, queue);
TextMessage message = session.createTextMessage();
@@ -231,4 +238,208 @@
getLog().debug(RequestReplyQueue passed);
}
+
+ public void testMessageListener() throws Exception{
+ getLog().debug(Starting MessageListener test);
+
+ connect();
+ queueConnection.start();
+ drainQueue();
+
+
[JBoss-dev] CVS update: jbosstest build.xml
User: dmaplesden
Date: 01/09/19 15:44:50
Modified:.build.xml
Log:
change one-test target to find tests in 'perf' directories as well
Revision ChangesPath
1.30 +2 -1 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- build.xml 2001/09/19 19:16:53 1.29
+++ build.xml 2001/09/19 22:44:50 1.30
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.29 2001/09/19 19:16:53 d_jencks Exp $ --
+!-- $Id: build.xml,v 1.30 2001/09/19 22:44:50 dmaplesden Exp $ --
project default=main name=JBoss/Testsuite
@@ -1841,6 +1841,7 @@
fileset dir=${build.classes}
include name=org/jboss/test/*/test/${test}.class/
+ include name=org/jboss/test/*/perf/${test}.class/
/fileset
/batchtest
/junit
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
Ok I have had a look at the mq tests and they run fine for me, I didn't have any trouble. The only thing I changed was to use the rollinglogged persistence manager instead of the file persistence manager for JBossMQ. This shouldn't change anything except the performance (rolling logged is many times faster), I only did it so the tests would finish in a reasonable time, as it was the JBossMQPerfStressTestCase took nearly 5 minutes to finish. I would imagine that with file persistence and running 1000 iterations the total time could take something like an 30 minutes to an hour (this is only a rough estimate based on my previous experience). During the test several errors are thrown out by the engine, looking at the code these errors are all created by the test code closing the session the message listener is registered with too soon. In other words these errors are difficult to avoid but harmless. The errors in particular I am talking about are [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. javax.jms.JMSException: Invalid transaction id. at org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceManager.java:62) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) at java.lang.Thread.run(Thread.java:484) or [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver at org.jboss.mq.Connection.receive(Connection.java:595) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) at java.lang.Thread.run(Thread.java:484) linked exception is: javax.jms.JMSException: The provided subscription does not exist no stack trace available These should happen at most once per run, and sometimes you get neither, if the timing of the threads closing down happens in the right order. Other than that everything seems fine to me. If you continue to have trouble let me know. Cheers David -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 8:21 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) I'll have a look, I've been through the MQ test stuff before and it did all work originally. I haven't looked at it since all the changes to the build system and new test stuff so its not too surprising if its having trouble. I'll let you know how I get on. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 7:35 AM To: jboss-dev Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) Hi, It appears that most of the jbossmq tests are not working currently with rh. Much of this appears to me to be configuration problems. On my machine, running JBossMQPerfStressTestCase usually freezes something so that subsequent tests don't run and jboss will not shut down: for this reason I commented it out of the testsuite/build.xml. Could the jbossmq experts take a look? You may find the ability to set counts via a local.properties file useful: ### Test properties junit.timeout=12 jbosstest.threadcount=2 jbosstest.iterationcount=2 jbosstest.beancount=2 You may find the one-test target useful: ./build.sh -DJBossMQPerfStressTestCase one-test runs only the named test. Thanks 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
For me the perf test freezes after one or two of these messages, which I always get. Doesn't matter which persistence manager I use. I'm attaching the server and client (test) logs. Any ideas? Strange... I'll have a look. btw, in the jbossmq unit test, would you mind using the getInitialContext() from JBossTestCase rather than new InitialContext()? I was hoping to get all the getting of initial contexts in one place in case we wanted to use properties passed from the build file to determine where we look. Sure thing, I didn't change this on purpose, it never existed in the original file which I edited and then it got lost when I merged my new tests with the new format. Thanks david jencks On 2001.09.19 18:53:25 -0400 David Maplesden wrote: Ok I have had a look at the mq tests and they run fine for me, I didn't have any trouble. The only thing I changed was to use the rollinglogged persistence manager instead of the file persistence manager for JBossMQ. This shouldn't change anything except the performance (rolling logged is many times faster), I only did it so the tests would finish in a reasonable time, as it was the JBossMQPerfStressTestCase took nearly 5 minutes to finish. I would imagine that with file persistence and running 1000 iterations the total time could take something like an 30 minutes to an hour (this is only a rough estimate based on my previous experience). During the test several errors are thrown out by the engine, looking at the code these errors are all created by the test code closing the session the message listener is registered with too soon. In other words these errors are difficult to avoid but harmless. The errors in particular I am talking about are [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. javax.jms.JMSException: Invalid transaction id. at org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceMana ger.java:62) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) at java.lang.Thread.run(Thread.java:484) or [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver at org.jboss.mq.Connection.receive(Connection.java:595) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) at java.lang.Thread.run(Thread.java:484) linked exception is: javax.jms.JMSException: The provided subscription does not exist no stack trace available These should happen at most once per run, and sometimes you get neither, if the timing of the threads closing down happens in the right order. Other than that everything seems fine to me. If you continue to have trouble let me know. Cheers David -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 8:21 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) I'll have a look, I've been through the MQ test stuff before and it did all work originally. I haven't looked at it since all the changes to the build system and new test stuff so its not too surprising if its having trouble. I'll let you know how I get on. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 7:35 AM To: jboss-dev Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) Hi, It appears that most of the jbossmq tests are not working currently with rh. Much of this appears to me to be configuration problems. On my machine, running JBossMQPerfStressTestCase usually freezes something so that subsequent tests don't run and jboss will not shut down: for this reason I commented it out of the testsuite/build.xml. Could the jbossmq experts take a look? You may find the ability to set counts via a local.properties file useful: ### Test properties junit.timeout=12 jbosstest.threadcount=2 jbosstest.iterationcount=2 jbosstest.beancount=2 You may find the one-test target useful: ./build.sh -DJBossMQPerfStressTestCase one-test runs only the named test. Thanks 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-development mailing list [EMAIL
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/perf JBossMQPerfStressTestCase.java
User: dmaplesden
Date: 01/09/19 18:06:30
Modified:src/main/org/jboss/test/jbossmq/perf
JBossMQPerfStressTestCase.java
Log:
change new InitialContext to getInitialContext
Revision ChangesPath
1.3 +1 -1
jbosstest/src/main/org/jboss/test/jbossmq/perf/JBossMQPerfStressTestCase.java
Index: JBossMQPerfStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/perf/JBossMQPerfStressTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JBossMQPerfStressTestCase.java2001/09/19 19:16:54 1.2
+++ JBossMQPerfStressTestCase.java2001/09/20 01:06:30 1.3
@@ -667,7 +667,7 @@
if (context == null)
{
- context = new InitialContext();
+ context = getInitialContext();
QueueConnectionFactory queueFactory =
(QueueConnectionFactory)context.lookup(QUEUE_FACTORY);
queueConnection = queueFactory.createQueueConnection();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server JMSTopic.java ClientConsumer.java
User: dmaplesden
Date: 01/09/19 20:52:57
Modified:src/main/org/jboss/mq/server JMSTopic.java
ClientConsumer.java
Log:
fixed bug for message acknowledgement after receiver closed for topics
Revision ChangesPath
1.5 +9 -2 jbossmq/src/main/org/jboss/mq/server/JMSTopic.java
Index: JMSTopic.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/JMSTopic.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JMSTopic.java 2001/08/17 03:04:06 1.4
+++ JMSTopic.java 2001/09/20 03:52:57 1.5
@@ -26,7 +26,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class JMSTopic extends JMSDestination {
@@ -86,7 +86,7 @@
DurableSubcriptionID id = topic.getDurableSubscriptionID();
if ( id == null ) {
synchronized ( tempQueues ) {
-queue = ( BasicQueue )tempQueues.remove( sub );
+queue = ( BasicQueue )tempQueues.get( sub );
}
} else {
synchronized ( durQueues ) {
@@ -97,6 +97,13 @@
queue.removeSubscriber( sub );
}
+ void cleanupSubscription(Subscription sub){
+ //just try to remove from tempQueues, don't worry if its not there
+ synchronized ( tempQueues ) {
+ tempQueues.remove( sub );
+ }
+ }
+
public void addReceiver( Subscription sub ) {
getQueue( sub ).addReceiver( sub );
}
1.6 +8 -2 jbossmq/src/main/org/jboss/mq/server/ClientConsumer.java
Index: ClientConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/ClientConsumer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ClientConsumer.java 2001/08/29 22:45:58 1.5
+++ ClientConsumer.java 2001/09/20 03:52:57 1.6
@@ -25,7 +25,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class ClientConsumer implements Runnable {
//The JMSServer object
@@ -256,8 +256,14 @@
}
void removeRemovedSubscription( int subId ) {
+ Subscription sub = null;
synchronized ( subscriptions ) {
- removedSubscriptions.remove( new Integer( subId ) );
+ sub = (Subscription) removedSubscriptions.remove( new Integer( subId ) );
+ }
+ if(sub != null){
+ JMSDestination topic = server.getJMSDestination( sub.destination );
+ if(topic instanceof JMSTopic)
+((JMSTopic) topic).cleanupSubscription(sub);
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILClientILService.java
User: dmaplesden
Date: 01/09/19 20:55:11
Modified:src/main/org/jboss/mq/il/oil OILClientILService.java
Log:
Improved error message when client side error received
Revision ChangesPath
1.3 +2 -2 jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java
Index: OILClientILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- OILClientILService.java 2001/08/17 03:04:04 1.2
+++ OILClientILService.java 2001/09/20 03:55:11 1.3
@@ -30,7 +30,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class OILClientILService implements Runnable,
org.jboss.mq.il.ClientILService {
//the client IL
@@ -183,7 +183,7 @@
}
try {
- cat.error( e );
+ cat.error( Exception handling server request, e );
out.writeByte( 1 );
out.writeObject( e );
out.reset();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
OK, took longer than I thought. There was a fundamental bug that was causing your freeze, but it was in code that only gets executed if something else is going wrong... So fixing the bug was simple, fixing every else just because it needed it took longer. Anyway I won't bore you with the details, it should work much better now (it works for me), let me know if it still doesn't. BTW: does Jetty hang on shutdown for anyone else? Happens every time for me. David. -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 12:57 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) For me the perf test freezes after one or two of these messages, which I always get. Doesn't matter which persistence manager I use. I'm attaching the server and client (test) logs. Any ideas? Strange... I'll have a look. btw, in the jbossmq unit test, would you mind using the getInitialContext() from JBossTestCase rather than new InitialContext()? I was hoping to get all the getting of initial contexts in one place in case we wanted to use properties passed from the build file to determine where we look. Sure thing, I didn't change this on purpose, it never existed in the original file which I edited and then it got lost when I merged my new tests with the new format. Thanks david jencks On 2001.09.19 18:53:25 -0400 David Maplesden wrote: Ok I have had a look at the mq tests and they run fine for me, I didn't have any trouble. The only thing I changed was to use the rollinglogged persistence manager instead of the file persistence manager for JBossMQ. This shouldn't change anything except the performance (rolling logged is many times faster), I only did it so the tests would finish in a reasonable time, as it was the JBossMQPerfStressTestCase took nearly 5 minutes to finish. I would imagine that with file persistence and running 1000 iterations the total time could take something like an 30 minutes to an hour (this is only a rough estimate based on my previous experience). During the test several errors are thrown out by the engine, looking at the code these errors are all created by the test code closing the session the message listener is registered with too soon. In other words these errors are difficult to avoid but harmless. The errors in particular I am talking about are [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. javax.jms.JMSException: Invalid transaction id. at org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceMana ger.java:62) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) at java.lang.Thread.run(Thread.java:484) or [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver at org.jboss.mq.Connection.receive(Connection.java:595) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) at java.lang.Thread.run(Thread.java:484) linked exception is: javax.jms.JMSException: The provided subscription does not exist no stack trace available These should happen at most once per run, and sometimes you get neither, if the timing of the threads closing down happens in the right order. Other than that everything seems fine to me. If you continue to have trouble let me know. Cheers David -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 8:21 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) I'll have a look, I've been through the MQ test stuff before and it did all work originally. I haven't looked at it since all the changes to the build system and new test stuff so its not too surprising if its having trouble. I'll let you know how I get on. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 7:35 AM To: jboss-dev Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) Hi, It appears that most of the jbossmq tests are not working currently with rh. Much of this appears to me to be configuration problems. On my machine, running JBossMQPerfStressTestCase usually freezes something so that subsequent tests don't run and jboss will not shut down: for this reason I commented it out of the testsuite/build.xml. Could the jbossmq experts take a look? You may find the ability to set counts via
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java Connection.java
User: dmaplesden
Date: 01/09/19 20:54:42
Modified:src/main/org/jboss/mq SpySession.java
SpyMessageConsumer.java Connection.java
Log:
fixed npe when a receive occurs after a subscription is closed. Also tidied up
closing down of sessions with receivers with message listeners.
Revision ChangesPath
1.4 +38 -36jbossmq/src/main/org/jboss/mq/SpySession.java
Index: SpySession.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpySession.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpySession.java 2001/08/17 03:04:01 1.3
+++ SpySession.java 2001/09/20 03:54:41 1.4
@@ -33,7 +33,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public abstract class SpySession
implements Session, XASession {
@@ -225,38 +225,40 @@
throws JMSException {
// allow other threads to process before closing this session
// Patch submitted by John Ellis (10/29/00)
- Thread.yield();
+// Thread.yield();
+ cat.debug(Session closing.);
- //deal with any unacked messages
- if ( !closed transacted spyXAResource == null ) {
- rollback();
- }
-
synchronized ( runLock ) {
+
if ( closed ) {
return;
}
- closed = true;
- }
-
- Iterator i;
- synchronized ( consumers ) {
- //notify the sleeping synchronous listeners
- if ( sessionConsumer != null ) {
-sessionConsumer.close();
+ Iterator i;
+ synchronized ( consumers ) {
+
+//notify the sleeping synchronous listeners
+if ( sessionConsumer != null ) {
+ sessionConsumer.close();
+}
+
+i = consumers.iterator();
}
-
- i = consumers.iterator();
- }
+
+ while ( i.hasNext() ) {
+SpyMessageConsumer messageConsumer = ( SpyMessageConsumer )i.next();
+messageConsumer.close();
+ }
+
+ //deal with any unacked messages
+ if ( transacted spyXAResource == null ) {
+rollback();
+ }
+
+ connection.sessionClosing( this );
- while ( i.hasNext() ) {
- SpyMessageConsumer messageConsumer = ( SpyMessageConsumer )i.next();
- messageConsumer.close();
+ closed = true;
}
-
- connection.sessionClosing( this );
-
}
@@ -298,21 +300,21 @@
//Rollback a transacted session
public synchronized void rollback()
throws JMSException {
- if ( spyXAResource != null ) {
- throw new javax.jms.TransactionInProgressException( Should not be call
from a XASession );
- }
- if ( closed ) {
- throw new IllegalStateException( The session is closed );
- }
- if ( !transacted ) {
- throw new IllegalStateException( The session is not transacted );
- }
- cat.debug( Session: rollback() );
-
- // Stop message delivery
synchronized ( runLock ) {
+ if ( spyXAResource != null ) {
+throw new javax.jms.TransactionInProgressException( Should not be call
from a XASession );
+ }
+ if ( closed ) {
+throw new IllegalStateException( The session is closed );
+ }
+ if ( !transacted ) {
+throw new IllegalStateException( The session is not transacted );
+ }
+
+ cat.debug( Session: rollback() );
+
// rollback transaction
try {
connection.spyXAResourceManager.endTx( currentTransactionId, true );
1.8 +14 -2 jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SpyMessageConsumer.java 2001/08/21 23:16:17 1.7
+++ SpyMessageConsumer.java 2001/09/20 03:54:41 1.8
@@ -23,7 +23,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class SpyMessageConsumer
implements MessageConsumer, SpyConsumer, Runnable
@@ -264,6 +264,8 @@
public void close()
throws JMSException {
+ cat.debug
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyTextMessage.java
User: dmaplesden
Date: 01/09/18 14:02:38
Modified:src/main/org/jboss/mq Tag: Branch_2_4 SpyTextMessage.java
Log:
Apply patch #437132 to Branch_2_4 (as requested)
Revision ChangesPath
No revision
No revision
1.2.2.2 +39 -4 jbossmq/src/main/org/jboss/mq/SpyTextMessage.java
Index: SpyTextMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTextMessage.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- SpyTextMessage.java 2001/08/23 03:57:08 1.2.2.1
+++ SpyTextMessage.java 2001/09/18 21:02:38 1.2.2.2
@@ -7,6 +7,7 @@
package org.jboss.mq;
import java.io.*;
+import java.util.ArrayList;
import javax.jms.JMSException;
import javax.jms.MessageNotWriteableException;
@@ -17,7 +18,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
public class SpyTextMessage
extends SpyMessage
@@ -28,7 +29,8 @@
String content = null;
private final static long serialVersionUID = 235726945332013953L;
-
+ private final static int chunkSize = 16384;
+
// Public
public void setText( String string )
@@ -65,7 +67,17 @@
if ( type == NULL ) {
content = null;
} else {
- content = in.readUTF();
+ // apply workaround for string 64K bug in jdk's 1.3.*
+
+ // Read the no. of chunks this message is split into, allocate
+ // a StringBuffer that can hold all chunks, read the chunks
+ // into the buffer and set 'content' accordingly
+ int chunksToRead = in.readInt();
+ StringBuffer sb = new StringBuffer(chunkSize * chunksToRead);
+ for (int i = 0; i chunksToRead; i++) {
+sb.append( in.readUTF() );
+ }
+ content = sb.toString();
}
}
@@ -75,8 +87,31 @@
if ( content == null ) {
out.writeByte( NULL );
} else {
+ // apply workaround for string 64K bug in jdk's 1.3.*
+
+ // Split content into chunks of size 'chunkSize' and assemble
+ // the pieces into a Vector ...
+ ArrayList v = new ArrayList();
+ int contentLength = content.length();
+
+ while (contentLength 0) {
+int beginCopy = (v.size()) * chunkSize;
+int endCopy = contentLength = chunkSize ?
+ beginCopy + contentLength : beginCopy + chunkSize;
+
+String theChunk = content.substring(beginCopy, endCopy);
+v.add(theChunk);
+
+contentLength -= chunkSize;
+ }
+
+ // Write out the type (OBJECT), the no. of chunks and finally
+ // all chunks that have been assembled previously
out.writeByte( OBJECT );
- out.writeUTF( content );
+ out.writeInt(v.size());
+ for (int i = 0; i v.size(); i++) {
+out.writeUTF( (String)v.get(i) );
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH, Jetty, testsuite, Exceptions...
I don't know anything about this test, but I can see one problem straight away, JBossMQ no longer uses the name QueueConnectionFactory in its default setup so unless you have changed the MQ configuration (which is unlikely, yes?) then the name that should be looked up by the test is just ConnectionFactory. Cheers David. -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 18, 2001 8:18 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RH, Jetty, testsuite, Exceptions... It looks like some new tests may have gone into the web test module. I am trying to get RH/Jetty to pass and have come up against the following : [Jetty] ENCServlet: init [Default] ejb/bean0 = ENCBean0Home [Default] ejb/bean1 = ENCBean1Home [Default] ejb/bean2 = ENCBean1Home [Default] ejb/UnsecuredEJB = jbosstest/ejbs/UnsecuredEJBHome [Default] ejb/SecuredEJB = jbosstest/ejbs/SecuredEJBHome [Default] jdbc/DefaultDS = org.jboss.resource.adapter.jdbc.JDBCDataSource@661fd1 [Default] mail/DefaultMail = javax.mail.Session@4ab2f [Default] javax.naming.NameNotFoundException: QueueConnectionFactory not bound [Default] at org.jnp.server.NamingServer.getBinding(Unknown Source) [Default] at org.jnp.server.NamingServer.getBinding(Unknown Source) [Default] at org.jnp.server.NamingServer.getObject(Unknown Source) [Default] at org.jnp.server.NamingServer.lookup(Unknown Source) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at javax.naming.InitialContext.lookup(InitialContext.java:350) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at org.jnp.interfaces.NamingContext.lookup(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.testJMS(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.testENC(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.processRequest(Unknown Source) [Default] at org.jboss.test.web.servlets.ENCServlet.doGet(Unknown Source) [Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) [Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [Default] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:488) [Default] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler .java:390) [Default] at org.mortbay.http.HandlerContext.handle(HandlerContext.java:1027) [Default] at org.mortbay.http.HandlerContext.handle(HandlerContext.java:982) [Default] at org.mortbay.http.HttpServer.service(HttpServer.java:674) [Default] at org.mortbay.http.HttpConnection.service(HttpConnection.java:732) [Default] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:889) [Default] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:746) [Default] at org.mortbay.http.SocketListener.handleConnection(SocketListene r.java:146) [Default] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) [Default] at org.mortbay.util.ThreadPool$PoolThreadRunnable.run(ThreadPool. java:613) [Default] at java.lang.Thread.run(Thread.java:484) [Jetty] Servlet Exception for /jbosstest/ENCServlet javax.naming.NameNotFoundException: QueueConnectionFactory not bound at org.jnp.server.NamingServer.getBinding(Unknown Source) at org.jnp.server.NamingServer.getBinding(Unknown Source) at org.jnp.server.NamingServer.getObject(Unknown Source) at org.jnp.server.NamingServer.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(Unknown Source) at javax.naming.InitialContext.lookup(InitialContext.java:350) at org.jnp.interfaces.NamingContext.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(Unknown Source) at org.jboss.test.web.servlets.ENCServlet.testJMS(Unknown Source) at org.jboss.test.web.servlets.ENCServlet.testENC(Unknown Source) at org.jboss.test.web.servlets.ENCServlet.processRequest(Unknown Source) at org.jboss.test.web.servlets.ENCServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:488) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler .java:390) at org.mortbay.http.HandlerContext.handle(HandlerContext.java:1027) at org.mortbay.http.HandlerContext.handle(HandlerContext.java:982) at org.mortbay.http.HttpServer.service(HttpServer.java:674) at org.mortbay.http.HttpConnection.service(HttpConnection.java:732) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:889) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:746) at org.mortbay.http.SocketListener.handleConnection(SocketListene r.java:146) at
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyTextMessage.java
User: dmaplesden
Date: 01/09/17 14:09:46
Modified:src/main/org/jboss/mq SpyTextMessage.java
Log:
Apply submitted patch for working around write/read utf limitation in jdk 1.3.*
Revision ChangesPath
1.3 +39 -4 jbossmq/src/main/org/jboss/mq/SpyTextMessage.java
Index: SpyTextMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyTextMessage.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SpyTextMessage.java 2001/08/17 03:04:01 1.2
+++ SpyTextMessage.java 2001/09/17 21:09:46 1.3
@@ -7,6 +7,7 @@
package org.jboss.mq;
import java.io.*;
+import java.util.ArrayList;
import javax.jms.JMSException;
import javax.jms.MessageNotWriteableException;
@@ -17,7 +18,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class SpyTextMessage
extends SpyMessage
@@ -28,7 +29,8 @@
String content = null;
private final static long serialVersionUID = 235726945332013953L;
-
+ private final static int chunkSize = 16384;
+
// Public
public void setText( String string )
@@ -65,7 +67,17 @@
if ( type == NULL ) {
content = null;
} else {
- content = in.readUTF();
+ // apply workaround for string 64K bug in jdk's 1.3.*
+
+ // Read the no. of chunks this message is split into, allocate
+ // a StringBuffer that can hold all chunks, read the chunks
+ // into the buffer and set 'content' accordingly
+ int chunksToRead = in.readInt();
+ StringBuffer sb = new StringBuffer(chunkSize * chunksToRead);
+ for (int i = 0; i chunksToRead; i++) {
+sb.append( in.readUTF() );
+ }
+ content = sb.toString();
}
}
@@ -75,8 +87,31 @@
if ( content == null ) {
out.writeByte( NULL );
} else {
+ // apply workaround for string 64K bug in jdk's 1.3.*
+
+ // Split content into chunks of size 'chunkSize' and assemble
+ // the pieces into a Vector ...
+ ArrayList v = new ArrayList();
+ int contentLength = content.length();
+
+ while (contentLength 0) {
+int beginCopy = (v.size()) * chunkSize;
+int endCopy = contentLength = chunkSize ?
+ beginCopy + contentLength : beginCopy + chunkSize;
+
+String theChunk = content.substring(beginCopy, endCopy);
+v.add(theChunk);
+
+contentLength -= chunkSize;
+ }
+
+ // Write out the type (OBJECT), the no. of chunks and finally
+ // all chunks that have been assembled previously
out.writeByte( OBJECT );
- out.writeUTF( content );
+ out.writeInt(v.size());
+ for (int i = 0; i v.size(); i++) {
+out.writeUTF( (String)v.get(i) );
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JSR/SAR (Jetty) Undeployment...
Ahh, this is a bug I came across about two weeks ago when developing my own mbean. It is actually a bug in the MBeanServerImpl when working with mbeans that use the default domain in the object name (i.e. :service=Jetty instead of SomeDomain:service=Jetty). It fails to find the mbean when it tries to unregister it, even though the call to isRegistered(mbean) returns true. Put a domain name in your object name the problem goes away. David. -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 12:09 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JSR/SAR (Jetty) Undeployment... Hot-deploying the Jetty service works fine. Hot-undeploying generates the following exception : [AutoDeployer] Auto undeploy of file:/mnt/megalodon/home/jules/cvs/JBoss/3.0/build/output/jbos s-3.0.0alpha/deploy/jetty-service.xml [JettyService] Stopping [Jetty] Stopped SocketListener on 0.0.0.0:8080 [JettyService] Stopped [JettyService] Destroying [Jetty] Destroy SocketListener on 0.0.0.0:8080 [Jetty] Deregister Jetty:Jetty=0,SocketListener=0 [JettyService] Destroyed [ServiceDeployer] Mbean exception while executing undeploy on [Ljava.lang.Object;@333a0e javax.management.InstanceNotFoundException: :service=Jetty at com.sun.management.jmx.MBeanServerImpl.unregisterMBean(MBeanSe rverImpl.java:945) at org.jboss.system.ServiceController.undeploy(ServiceController. java:248) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.deployment.ServiceDeployer.invoke(ServiceDeployer.java:949) at org.jboss.deployment.ServiceDeployer.undeploy(ServiceDeployer. java:681) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.deployment.AutoDeployer.undeploy(AutoDeployer.java:664) at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:270) at java.lang.Thread.run(Thread.java:484) It looks like the service was located and successfully shut down and destroyed. Then something went wrong. Is this a known problem in undeployment, or something peculiar to the Jetty service. Perhaps Jetty's own MBeans are confusing the issue - I'll run some tests... I would like to get it fixed, as it will speed my development cycle substantially if I can bounce just the Jetty service, and not the whole server, each time I recompile my stuff. Thanks, Guys, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ 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] CVS update: jbosscx/src/resources/jca-sar/META-INF jboss-service.xml
User: dmaplesden Date: 01/09/12 16:06:52 Modified:src/resources/jca-sar/META-INF jboss-service.xml Log: Change default configuration to start RARDeployer before AutoDeployer Revision ChangesPath 1.3 +1 -5 jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-service.xml 2001/09/11 02:48:21 1.2 +++ jboss-service.xml 2001/09/12 23:06:52 1.3 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: jboss-service.xml,v 1.2 2001/09/11 02:48:21 dmaplesden Exp $ -- +!-- $Id: jboss-service.xml,v 1.3 2001/09/12 23:06:52 dmaplesden Exp $ -- !-- | This contains configuration for the RARDeployer and the @@ -31,10 +31,6 @@ !-- The RARDeployer and three Connection Manager Factories are parts of -- !-- JBoss and do not need further configuration. -- !-- -- - - mbean code=org.jboss.resource.RARDeployer - name=JCA:service=RARDeployer - /mbean !-- | Minerva no transaction connection manager factory. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss-service.xml
User: dmaplesden Date: 01/09/12 16:06:40 Modified:src/etc/conf/default jboss-service.xml Log: Change default configuration to start RARDeployer before AutoDeployer Revision ChangesPath 1.12 +6 -1 jboss/src/etc/conf/default/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- jboss-service.xml 2001/09/11 05:28:08 1.11 +++ jboss-service.xml 2001/09/12 23:06:40 1.12 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: jboss-service.xml,v 1.11 2001/09/11 05:28:08 user57 Exp $ -- +!-- $Id: jboss-service.xml,v 1.12 2001/09/12 23:06:40 dmaplesden Exp $ -- !-- | This is where you can add and configure your MBeans. @@ -67,6 +67,7 @@ jts.jar, mail.jar, org.apache.jasper.jar, + RARDeployer.jar, tyrex.jar, tyrex-tm-plugin.jar, xalan.jar/ @@ -74,6 +75,10 @@ !-- -- !-- Auto deployment -- !-- -- + + mbean code=org.jboss.resource.RARDeployer + name=JCA:service=RARDeployer + /mbean mbean code=org.jboss.deployment.AutoDeployer name=JBOSS-SYSTEM:service=AutoDeployer attribute name=Deployers ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx build.xml
User: dmaplesden
Date: 01/09/12 16:07:03
Modified:.build.xml
Log:
Change default configuration to start RARDeployer before AutoDeployer
Revision ChangesPath
1.13 +9 -1 jbosscx/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosscx/build.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- build.xml 2001/09/12 03:08:10 1.12
+++ build.xml 2001/09/12 23:07:03 1.13
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.12 2001/09/12 03:08:10 dmaplesden Exp $ --
+!-- $Id: build.xml,v 1.13 2001/09/12 23:07:03 dmaplesden Exp $ --
project default=main name=JBoss/Connector
@@ -346,6 +346,14 @@
--
target name=jars depends=compile description=Builds all jar files.
mkdir dir=${build.lib}/
+
+!-- Build RARDeployer.jar --
+jar jarfile=${build.lib}/RARDeployer.jar
+ fileset dir=${build.classes}
+include name=**/RARDeployer*.class/
+include name=**/RARMetaData*.class/
+ /fileset
+/jar
!-- Build jbosscx.sar --
jar jarfile=${build.lib}/jbosscx.sar
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: dmaplesden
Date: 01/09/12 16:16:04
Modified:jbossbuild.xml
Log:
Change default configuration to start RARDeployer before AutoDeployer
Revision ChangesPath
1.26 +21 -26build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- build.xml 2001/09/12 02:10:22 1.25
+++ build.xml 2001/09/12 23:16:04 1.26
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.25 2001/09/12 02:10:22 schaefera Exp $ --
+!-- $Id: build.xml,v 1.26 2001/09/12 23:16:04 dmaplesden Exp $ --
project default=main name=JBoss/Build
@@ -652,67 +652,61 @@
/fileset
/copy
-!-- Copy the mail service xml snippet (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the mail service xml snippet (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=mail-service.xml/
/fileset
/copy
-!-- Copy the core service xml snippet (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the core service xml snippet (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=core-service.xml/
/fileset
/copy
-!-- Copy the jetty service xml snippet (deploy/lib)
+!-- Copy the jetty service xml snippet (deploy)
Disable for the moment
-copy todir=${install.deploy.lib} filtering=no
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=jetty-service.xml/
/fileset
/copy
--
-!-- Copy the jbossmq service xml snippet (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
- fileset dir=${_module.output}/etc/conf/default
- include name=jbossmq-service.xml/
- /fileset
-/copy
-!-- Copy the jms service xml snippet (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the jms service xml snippet (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=jms-service.xml/
/fileset
/copy
-!-- Copy the j2eedeployment service xml snippet (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the j2eedeployment service xml snippet (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=j2eedeployment-service.xml/
/fileset
/copy
-!-- Copy the hsql defaultds service xml snippet (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the hsql defaultds service xml snippet (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=hsql-default-service.xml/
/fileset
/copy
-!-- Copy the jmx-adaptor.jsr (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the jmx-adaptor.jsr (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/lib
include name=jmx-html-adaptor.jsr/
/fileset
/copy
-!-- Copy the jmx-rmi-connector.jsr (deploy/lib) --
-copy todir=${install.deploy.lib} filtering=no
+!-- Copy the jmx-rmi-connector.jsr (deploy) --
+copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/lib
include name=jmx-rmi-connector.jsr/
/fileset
@@ -744,7 +738,6 @@
!--exclude name=default/jetty-service.xml/--
exclude name=default/jms-service.xml/
exclude name=default/j2eedeployment-service.xml/
- exclude name=default/jbossmq-service.xml/
exclude name=default/hsql-default-service.xml/
/fileset
/copy
@@ -866,6 +859,7 @@
copy todir=${install.lib.ext} filtering=no
fileset dir=${_module.output}/lib
include name=jbosscx.sar/
+ include name=RARDeployer.jar/
/fileset
/copy
@@ -896,8 +890,9 @@
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!-- Copy the jbossmq service xml snippet (deploy/lib) --
-copy
RE: [JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-INF jboss-service.xml
I thought you might notice this. It did make a lot of sense to have it all in one place but it causes problems when loading mbeans that lookup the DefaultDS in their initialisation. I have a custom mbean I am deploying in JBoss and if it gets deployed before the various RAR files are deployed then the lookup of the DataSource fails. Currently there is no way to test if the rar files have been deployed or not, so the only way I could solve the problem was to guarantee the rar files are deployed first by starting the RARDeployer before the AutoDeployer and moving all the service.xml files etc into the deploy directory which gets deployed after the deploy/lib directory. If you can think of another solution I would like to hear it. Cheers, David. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-INF jboss-service.xml David, what problem are you solving by splitting up this package? I thought it made a lot of sense to have all the jca stuff in one package. david jencks On 2001.09.12 19:06:52 -0400 David Maplesden wrote: User: dmaplesden Date: 01/09/12 16:06:52 Modified:src/resources/jca-sar/META-INF jboss-service.xml Log: Change default configuration to start RARDeployer before AutoDeployer Revision ChangesPath 1.3 +1 -5 jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/resources/jca-sar/META-INF/jboss-se rvice.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-service.xml 2001/09/11 02:48:21 1.2 +++ jboss-service.xml 2001/09/12 23:06:52 1.3 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: jboss-service.xml,v 1.2 2001/09/11 02:48:21 dmaplesden Exp $ -- +!-- $Id: jboss-service.xml,v 1.3 2001/09/12 23:06:52 dmaplesden Exp $ -- !-- | This contains configuration for the RARDeployer and the @@ -31,10 +31,6 @@ !-- The RARDeployer and three Connection Manager Factories are parts of -- !-- JBoss and do not need further configuration. -- !-- -- - - mbean code=org.jboss.resource.RARDeployer - name=JCA:service=RARDeployer - /mbean !-- | Minerva no transaction connection manager factory. ___ 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-IN F jboss-service.xml
? That way if one of the listed packages provides a needed mbean deployment can proceed automatically. Thanks david jencks On 2001.09.12 22:10:37 -0400 David Maplesden wrote: I thought you might notice this. It did make a lot of sense to have it all in one place but it causes problems when loading mbeans that lookup the DefaultDS in their initialisation. I have a custom mbean I am deploying in JBoss and if it gets deployed before the various RAR files are deployed then the lookup of the DataSource fails. Currently there is no way to test if the rar files have been deployed or not, so the only way I could solve the problem was to guarantee the rar files are deployed first by starting the RARDeployer before the AutoDeployer and moving all the service.xml files etc into the deploy directory which gets deployed after the deploy/lib directory. If you can think of another solution I would like to hear it. Cheers, David. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-INF jboss-service.xml David, what problem are you solving by splitting up this package? I thought it made a lot of sense to have all the jca stuff in one package. david jencks On 2001.09.12 19:06:52 -0400 David Maplesden wrote: User: dmaplesden Date: 01/09/12 16:06:52 Modified:src/resources/jca-sar/META-INF jboss-service.xml Log: Change default configuration to start RARDeployer before AutoDeployer Revision ChangesPath 1.3 +1 -5 jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/resources/jca-sar/META-INF/jboss-se rvice.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-service.xml 2001/09/11 02:48:21 1.2 +++ jboss-service.xml 2001/09/12 23:06:52 1.3 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: jboss-service.xml,v 1.2 2001/09/11 02:48:21 dmaplesden Exp $ -- +!-- $Id: jboss-service.xml,v 1.3 2001/09/12 23:06:52 dmaplesden Exp $ -- !-- | This contains configuration for the RARDeployer and the @@ -31,10 +31,6 @@ !-- The RARDeployer and three Connection Manager Factories are parts of -- !-- JBoss and do not need further configuration. -- !-- -- - - mbean code=org.jboss.resource.RARDeployer - name=JCA:service=RARDeployer - /mbean !-- | Minerva no transaction connection manager factory. ___ 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-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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-IN F jboss-service.xml
-Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 4:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-IN F jboss-service.xml On 2001.09.12 23:22:40 -0400 David Maplesden wrote: 1. doesn't work, I tried it hoping it would. The problem is not when the RARDeployer is deployed but when the rar's themselves are deployed. It is easy to specify (using a depends tag or the classpath element) that the RARDeployer or indeed the entire jbosscx.sar needs to be deployed before my mbean, the trouble is this does not neccessarily deploy the rar's. The way you originally had the configuration with two AutoDeployers (one in the jbosscx.sar) this would have worked, but when I changed the AutoDeployer so that it could wait for the Deployers it uses to be deployed after itself then I removed the AutoDeployer from the jbosscx.sar because it really isn't needed. Of course now one way of fixing the problem would be to have this extra AutoDeployer again, but I'm not sure I like having two AutoDeployers just for this reason. I think until we think of a better solution having 2 autodeployers is better than splitting up the jbosscx.sar. I thought the opposite, but whatever, its really a case of six of one, half a dozen of the other. If you want to change it back then do so. After a quick look at the autodeployer, it looks to me as if it might help to try to deploy all possible files as soon as a deployer is registered. It looks to me as if currently the autodeployer will wait till the next scan to use the newly registered deployer. I think this might help but its not guaranteed to fix the problem. 2. Sounds feasible and desirable. I had a similar idea except that instead of having to specify these primary sars in the main jboss-service.xml file you could just put them in the deploy lib and everything would work nicely. This means however that we are going to run into problems with specifying dependencies between rar's and sar's or between ear's and sar's or even between ear's and rar's! Basically there is no mechanism at present to specify a dependency between files destined for different deployers, which is the problem I am having. The only way to really do this of course would be in the AutoDeployer itself but that would require some other mechanism because the AutoDeployer doesn't know anything about the content of the files it is deploying, maybe a naming scheme? I agree there is a big problem with autodeploy order - you can specify some things with ordering the deployers and the directories, but this is shaky at best. How about a more generalized/unified deployment architecture? At least ejb jars and ear's are allowed to have more configuration files in them, why not put a jboss-service.xml file in that can refer to the application.xml and external files (or internal jars for use in mbeans, as I think you suggest below.) so... Any kind of file goes into the universal deployer. First we look for a jboss-service.xml which will specify external sar, jar, rar, ear, war dependencies that should be deployed first a scope for the classloaders for this stuff (? not sure about this) internal jar, rar, (ejb) jar dependencies (as you suggest below) may reference application.xml, ejb-jar.xml, ra.xml (although I'm not sure what info would be conveyed) mbean dependencies mbean configuration The deployer will unpack the contained packages and feed the internal and external dependencies to the appropriate deployers. Then it would deploy using the application.xml or ejb-jar.xml or ra.xml or... If there is no jboss-service.xml, it will skip that step and treat it like a regular rar, ear, or whatever. It seems to me that all these deployers have 2 stages, -create some classloaders and make the classes available -interpret some configuration info. maybe we can make the first step shared among all the deployers, and get similar recycling classloaders everywhere. Does this make sense to you? OK the more I think about it the more I think that only the AutoDeployer needs to know anything about deployment dependencies. It is the autodeploy the controls the ordering of the deployment and if people are manually deploying their apps then I think we just have to rely on them doing it in the right order. So perhaps we shouldn't have any deployment dependencies in the jboss-service.xml file at all but have some way of conveying to the AutoDeployer what the dependencies are on any type of file. How we do this I don't know, perhaps have a special xml file type that the AutoDeployer looks for and reads before it deploys anything else. Then we can specify the dependencies between the files in that file and as all
RE: [JBoss-dev] How to build now?
I just got a clean copy of everything from CVS, and built it from scratch...
well tried to.
I still got the error below so I had to change those two properties again to
property name=executemodules.header value=Executing '${target}' in
module '${module}'.../
property name=executemodules.footer value=...Finished with
'${target}' in module '${module}'./
this must be something that comes up under win2k but not linux? Although it
never occurred for me before yesterday.
Anyway apart from that everything built fine, including Jetty.
When I tried to run it I got some errors from Jetty and on shut down all
hell broke loose (on the Jetty shutdown). Running without Jetty everything
is fine.
David.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 5:50 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] How to build now?
I don't see this, could you try this again with the latest changes.
--jason
On Tue, 11 Sep 2001, David Maplesden wrote:
I just had the same thing, its complaining about the lines...
property name=executemodules.header![CDATA[
==
== Executing '${target}' in module '${module}'...
==]]/property
property name=executemodules.footer![CDATA[
==
== Finished with '${target}' in module '${module}'.
==
]]/property
.. if that's any help.
David
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 3:45 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] How to build now?
I get the following error on Win2k. I had to revert to an
older build.bat
to get it to compile
D:\main\jboss-all\jboss-all\buildbuild.bat
Calling ..\tools\bin\ant.bat
Buildfile: build.xml
BUILD FAILED
D:\main\jboss-all\jboss-all\build\build.xml:276: You must
specify value,
locatio
n or refid with the name attribute
Total time: 4 seconds
D:\main\jboss-all\jboss-all\build
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Jason
Dillon
Sent: Monday, September 10, 2001 11:23 PM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: Re: [JBoss-dev] How to build now?
jboss-all, then `build/build.bat` should build the
cluster module.
jboss-most will work too, but I suggest jboss-all.
--jason
On Mon, 10 Sep 2001, Bill Burke wrote:
I gotten lastest in awhile. How do I build now? I want
to build the
cluster module on Win2k. Do I get jboss-most?
jboss-all? or what?
Thanks,
Bill
___
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-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-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: dmaplesden
Date: 01/09/11 14:47:49
Modified:jbossbuild.xml
Log:
Remove jetty from default config as it is not working for many people.
Also change property elements that were causing problems under win2k.
Revision ChangesPath
1.22 +9 -14 build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- build.xml 2001/09/11 09:16:36 1.21
+++ build.xml 2001/09/11 21:47:49 1.22
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.21 2001/09/11 09:16:36 user57 Exp $ --
+!-- $Id: build.xml,v 1.22 2001/09/11 21:47:49 dmaplesden Exp $ --
project default=main name=JBoss/Build
@@ -328,16 +328,8 @@
property name=executemodules.skipmissing value=true/
!-- The header and footer displayed during each module execution --
-property name=executemodules.header![CDATA[
-==
-== Executing '${target}' in module '${module}'...
-==]]/property
-
-property name=executemodules.footer![CDATA[
-==
-== Finished with '${target}' in module '${module}'.
-==
-]]/property
+property name=executemodules.header value=Executing '${target}' in module
'${module}'.../
+property name=executemodules.footer value=Finished with '${target}' in
module '${module}'./
!-- Install/Release structure --
property name=install.id value=${module.name}-${module.version}/
@@ -666,13 +658,16 @@
/fileset
/copy
-!-- Copy the jetty service xml snippet (deploy/lib) --
+!-- Copy the jetty service xml snippet (deploy/lib)
+
+Disable for the moment
+
copy todir=${install.deploy.lib} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=jetty-service.xml/
/fileset
/copy
-
+--
!-- Copy the jbossmq service xml snippet (deploy/lib) --
copy todir=${install.deploy.lib} filtering=no
fileset dir=${_module.output}/etc/conf/default
@@ -731,7 +726,7 @@
include name=**/*/
exclude name=default/mail-service.xml/
exclude name=default/core-service.xml/
- exclude name=default/jetty-service.xml/
+ !--exclude name=default/jetty-service.xml/--
exclude name=default/jms-service.xml/
exclude name=default/j2eedeployment-service.xml/
exclude name=default/jbossmq-service.xml/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] How to build now?
I just changed the default configuration to not deploy jetty by default, as
it not really very stable at the moment. It is still easy to deploy Jetty
manually, just copy the jetty-service.xml file from conf/default to one of
the deployment dirs. You will also have to edit it to set the jetty home
property and change j2eedeployment-service.xml if you want to deploy web
apps.
This entailed changing the main build.xml file (where it copies the
*-service.xml files) and so I changed those two troublesome property lines
at the same time.
Jason, if you want to undo this, feel free, but they do seem to be causing
problems under some platforms.
(i.e. under mine which is win2k and sun's jre 1.3.1)
David
-Original Message-
From: David Maplesden [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 9:24 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] How to build now?
I just got a clean copy of everything from CVS, and built it
from scratch...
well tried to.
I still got the error below so I had to change those two
properties again to
property name=executemodules.header value=Executing
'${target}' in
module '${module}'.../
property name=executemodules.footer value=...Finished with
'${target}' in module '${module}'./
this must be something that comes up under win2k but not
linux? Although it
never occurred for me before yesterday.
Anyway apart from that everything built fine, including Jetty.
When I tried to run it I got some errors from Jetty and on
shut down all
hell broke loose (on the Jetty shutdown). Running without
Jetty everything
is fine.
David.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 5:50 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] How to build now?
I don't see this, could you try this again with the latest changes.
--jason
On Tue, 11 Sep 2001, David Maplesden wrote:
I just had the same thing, its complaining about the lines...
property name=executemodules.header![CDATA[
==
== Executing '${target}' in module '${module}'...
==]]/property
property name=executemodules.footer![CDATA[
==
== Finished with '${target}' in module '${module}'.
==
]]/property
.. if that's any help.
David
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 3:45 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] How to build now?
I get the following error on Win2k. I had to revert to an
older build.bat
to get it to compile
D:\main\jboss-all\jboss-all\buildbuild.bat
Calling ..\tools\bin\ant.bat
Buildfile: build.xml
BUILD FAILED
D:\main\jboss-all\jboss-all\build\build.xml:276: You must
specify value,
locatio
n or refid with the name attribute
Total time: 4 seconds
D:\main\jboss-all\jboss-all\build
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Jason
Dillon
Sent: Monday, September 10, 2001 11:23 PM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: Re: [JBoss-dev] How to build now?
jboss-all, then `build/build.bat` should build the
cluster module.
jboss-most will work too, but I suggest jboss-all.
--jason
On Mon, 10 Sep 2001, Bill Burke wrote:
I gotten lastest in awhile. How do I build now? I want
to build the
cluster module on Win2k. Do I get jboss-most?
jboss-all? or what?
Thanks,
Bill
___
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-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-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] CVS update: jboss/src/etc/conf/default jetty-service.xml j2eedeployment-service.xml
User: dmaplesden Date: 01/09/11 14:46:11 Modified:src/etc/conf/default jetty-service.xml j2eedeployment-service.xml Log: Remove jetty from default config as it is not working for many people Revision ChangesPath 1.2 +1 -1 jboss/src/etc/conf/default/jetty-service.xml Index: jetty-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jetty-service.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jetty-service.xml 2001/09/11 02:48:05 1.1 +++ jetty-service.xml 2001/09/11 21:46:11 1.2 @@ -17,7 +17,7 @@ -- mbean code=org.jboss.jetty.JettyService name=:service=Jetty -attribute name=JettyHomeW:/Jetty-3.1.RC8/attribute +attribute name=JettyHomeyour-Jetty-3.1.RC9-home/attribute attribute name=Configuration../conf/default/jetty.xml/attribute attribute name=WebDefault../conf/default/webdefault.xml/attribute attribute name=UnpackWarstrue/attribute 1.2 +1 -1 jboss/src/etc/conf/default/j2eedeployment-service.xml Index: j2eedeployment-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/j2eedeployment-service.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- j2eedeployment-service.xml2001/09/11 02:48:05 1.1 +++ j2eedeployment-service.xml2001/09/11 21:46:11 1.2 @@ -3,7 +3,7 @@ server dependsJBOSS-SYSTEM:service=Naming/depends - depends:service=Jetty/depends + !--depends:service=Jetty/depends-- !-- -- !-- J2EE deployment -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
