Re: [JBoss-dev] [JBoss-user] capacity planning to use jboss
Some additional comments: 1) If a hardware load balancer is out of the budget (Cisco local director series start at about $4000 - not too expensive), then I would recommend looking at Linux Virtual Server (http://www.linuxvirtualserver.org/). It is basically a customized Linux kernel to do the same stuff as the hardware solution. 2) We do not want to use clustered http sessions, because frankly our sessions are too damn bloated (yeah - we need to fix that, but alas there is only so much time in a day). I was thinking about a way to cluster just enough session info to preserve login context, but to ignore the rest of the junk that is not needed (most of the our http session info is just database cache that can be recreated as needed). Basically, the clustered servers would only share session-id/login-id pairs. I haven't spent any time actually working on this, but I would love to hear comments. Might this be useful to others? -Larry - You'll probably want to buy some Hardware based HTTP load-balancer for your web traffic. Make sure it supports sticky sessions. You can try Apache + modjk + AJP13 if you want a cheap software solution. Jetty and Tomcat can be hooked in. - Do you require HTTP Session replication and failover? If its ok for a user to relogin after a failover, I suggest not using JBoss clustering features at all, (Except for net boot and maybe farming). - On the performance tests I ran(ECPERF), replication had a 10% hit on performance for 2 boxes running in a cluster. You'll probably have more than 2 boxes(but not much more). - I suggest marrying the WEB and EJB layer into one JVM/process. You'll get better performance. - Next what you have to do is guess peak traffic. Multiply that number by 2 just to be safe. - Next you'll need to write a stress test program - Next you'll need to hire JBossGroup to help you out with all of this. :) - Next you'll need to purchase a high quality support contract from JBossGroup to iron out any problems you may have :) At Mercantec we had 2 dual 900mhz CPU running Linux and JBoss, 1 dual 900Mgz PIII running Oracle. We could support traffic from 10K merchants. But that's our application. How many users your app can support on a given piece of hardware is totally dependent on the type of application you're running. DON'T USE CLUSTERING UNLESS YOU HAVE TO! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, October 16, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JBoss-user] capacity planning to use jboss Today i got a question from my manager (i work in a bank, there will be a web layer at the bank office and a central ejb layer) : Emerson, how many boxes in the ejblayer do we need to support 800 offices and more than 4000 simultaneous clients (from the offices). Imagine that you have available any number of xeon dual 2mhz with 2giga RAM connected through a gigabit lan, how many boxes of this kind do we need? I confess that i exitated a little. This is a though question, indeed. I think that CMP and mainly clustering will not have the same gain when you have too many nodes in the cluster, given the communication needed among the nodes to keep the data replicated. Does any one have any parameter for a capacity plan for a scenario like this? jboss group, any clue ?? What could be the limit beetwen number of nodes and replication overhead? Thanks in advance for any answer : ) -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
I have finally downloaded and tested this patch with SwiftMQ, and it does indeed fix the problem. Does anyone object if I go forward with this patch? (Note - I simplified it a bit, and added some (too much?) commenting). -Larry I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(join), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry 3.0.diff Description: Binary data
[JBoss-dev] Jetty jar file
Is the org.mortbay.jetty.jar file swappable with the latest cvs builds from mortbay? It seems to work for me, but I was wondering if there are any known issues. Thanks -Larry
Re: [JBoss-dev] sar startup ordering
OK- I agree. I will modify the existing PrefixDeploymentSorter.java. I will also make it the default comparator in jboss-system.xml. Should I aply these changes to Branch_3_0? -Larry Yes, that is the only way that makes sence for me at least. I've submitted my sorter to patches... Best regards, Per Your applications depends on the system beind deployed so you better put your numbered deployments at the end. marcf |The best solution I have found is to use the classpath... / tag in your |default jboss-service.xml. Certainly putting it in your jboss-system.jar |seems a bit extreme. | |-Larry | | I ended up creating my own Comparator since i want the non-numbered files |to | deploy first using the rules of the DeploymentSorter and then deploy | according to their numbered prefix. In order to actually use is however, |the | only way I found that worked was to add my class to jboss-system.jar, | otherwise i got a ClassNotFoundException (e.g. when jaring it up and |putting | the jar in lib). Is this a bug or intended? | | Best regards, | Per | | This has been available since (I think) 3.0 RC2. Take a look at | the default | jboss-service.xml file. At the bottom in the Deployment | Scanning section, | look for an attribute named URLComparator. The default comparator | (DeploymentSorter) sorts by type in this order: *.sar, *service.xml, |*rar, | *jar, *war, *wsr, *ear, *zip, *. | | There is a second comparator (commented out) called | PrefixDeploymentSorter. | If you use this then all deployments that start with a numeric prefix |will | be deployed in order of those prefixes. Non-prefixed deployments are | deployed last. Ties are broken using the sorting from DeploymentSorter | above. | | If this is still not cutting it, then you are free to implement | an instance | of java.util.Comparator that is capable of comparing two URL objects. | | -Larry | | I've been trying to find what was decided for how to specify in | what order | sar archives should be loaded and started, but the mail discussions |I've | found points in many different directions. Could anyone please set me | straight? | | I have a jxta.sar that i want to start before a ozone.sar | From what i can see from testing the following works: | | 1. Label them 10-jxta.sar and 20-ozone.sar | | 2. keep the names but make sure the timestamp of the jxta.sar is |earlier | than the ozone.sar | | Is there any mechanism that allows this behaviour to be configured? | | Best regards, | Per ___ 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] Where should the Jasper jar live ?
To recap: deployment type | Advantages |Disadvantages - .sar archive | 1 file | Pain in the ass to configure | digital signature | | It already works| - exploded sar | All files organized | Multiple files are exposed |within one directory |(potentially many jar files) | Uses same structure as | Can not use jar-signing |.sar archive |techniques | Easy to configure | | It already works| - external config | 2 files | Must distribute as 2 files | Easy to configure | Not set up like j2ee archives | | Doesn't work yet - I propose we allow the following: For any configuration file (or deployment descriptor) that exists within an archive, we allow an external version to override it. Ex: jetty.sar (fully compressed, with META-INF/jboss-service.xml) jetty_jboss-service_override.xml (Or something. I suck at coming up with names.) This would give us the best of all solutions. Sar's can be shipped with an embedded factory default configuration, and the user can easily override those settings by adding a configuration if they need it. Also, this gives a simple place for MBean configuration changes to be persisted. What do you think? -Larry ___ 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] Jetty jar file
Is there a particular issue that you are trying to resolve, or are you just a compulsive neophile :-) ? Well, that and the fact that I am having problems with request.getContextPath() that I'm hoping the latest Jetty fixes. It now appears that it did not - oh well. ___ 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] Where should the Jasper jar live ?
digi sigs will not work when you need to change the config. it is only useful if you have static config and want to ensure that the contents do not change. the second you need to chagne the config, you must resign... Right. The point is, it can be distributed with a signature, as long as you don't need to do any custom configuration. The major disadvantage of this is the added complextity of the configuration... I (and it sounds like Marc and Jules are with me) will forever disagree with you on the usefulness of exploded archives. I find them useful - you don't. I do agree that they are not the perfect solution, and you also agree that it simplifies things at least a little. I'm content to leave it at that. So, this does work. Why do you believe it does not? Mental hicup. Of course you are right, the separate configurations do indeed work. Fuck J2EE config, that is a fucking mess. I am inclined to agree with you here - configuring an ejb is a pain in the ass. I listed it as a disadvantage simply because it is different than what users are used to. An must distribute as 2 files? What? Now you are talking about distribution, or do you mean deployment? There are a number of deployments that rarely (or never) need any custom configuration. In these cases, the best solution is the traditional .sar with config included. To make them shuffle 2 files is not a huge deal, but I do count it as a disadvantage. I propose we allow the following: For any configuration file (or deployment descriptor) that exists within an archive, we allow an external version to override it. Ex: jetty.sar (fully compressed, with META-INF/jboss-service.xml) jetty_jboss-service_override.xml (Or something. I suck at coming up with names.) No, why do we need this at all? Who are we trying to cater too here? Who will beninfit most from the simple solution (option c), and how will beninift from the others. I am not suggesting we make it impossible to get a or b if they want... but I am suggestion that users who want a or b have specific needs which we can not and must not assume that all of our users will have. Option a is best for those deployment's where you never need to touch a configuration file. Option b is best for people developing something that will eventually be deployed as an Option a. Option c is best for 3rd party deployments where custom configuration is needed. I think we agree here, yes? My proposal offers a solution to two additional problems. 1) How do we persist configuration changes 2) What's the best way to distribute a deployment that rarely needs configuration. We need to solve the persistent configuration problem anyway. The solution that jumps to mind (support an external configuration file that overrides the internal one) also happens to provide an answer for problem 2. -Larry ___ 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] Possible to use Jikes to compile Jsp with Jetty?
This was killing us too. To solve this, we developed two tools: 1) An ant task that invokes jasper's jspc to translate jsps. 2) A wrapper servlet around jasper that will first check for and use a precompiled jsp if it exists, and if not fall back to the default mode of translating / compiling at runtime. If you are interested, I can send you the code. -Larry - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 29, 2002 11:14 PM Subject: [JBoss-dev] Possible to use Jikes to compile Jsp with Jetty? If so, can some one explain this to me. Jsp compiles are killing us on the website, hard to test new versions... --jason ___ 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 ___ 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] sar startup ordering
This has been available since (I think) 3.0 RC2. Take a look at the default jboss-service.xml file. At the bottom in the Deployment Scanning section, look for an attribute named URLComparator. The default comparator (DeploymentSorter) sorts by type in this order: *.sar, *service.xml, *rar, *jar, *war, *wsr, *ear, *zip, *. There is a second comparator (commented out) called PrefixDeploymentSorter. If you use this then all deployments that start with a numeric prefix will be deployed in order of those prefixes. Non-prefixed deployments are deployed last. Ties are broken using the sorting from DeploymentSorter above. If this is still not cutting it, then you are free to implement an instance of java.util.Comparator that is capable of comparing two URL objects. -Larry - Original Message - From: Per Nyfelt [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 6:29 AM Subject: [JBoss-dev] sar startup ordering I've been trying to find what was decided for how to specify in what order sar archives should be loaded and started, but the mail discussions I've found points in many different directions. Could anyone please set me straight? I have a jxta.sar that i want to start before a ozone.jar From what i can see from testing the following works: 1. Label them 10-jxta.jar and 20-ozone.jar 2. keep the names but make sure the timestamp of the jxta.jar is earlier than the ozone.jar Is there any mechanism that allows this behaviour to be configured? Best regards, Per ___ 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 ___ 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] deploy error in scanner thread (cvs head)
There is a bug in Sun's 1.3 jvm. Inner classes can not access protected members inherited from the outer class's super class: A (defines protected field: log) B extends A +-- C (Inner class of B) Trying to access log from C fails. This is why all inner-classes of MainDeployer called the public method getLog() instead of accessing log directly. -Larry - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Justin Casp [EMAIL PROTECTED] Sent: Monday, May 20, 2002 9:28 AM Subject: Re: [JBoss-dev] deploy error in scanner thread (cvs head) Chances are this is due to a problem accessing the Logger log field... when did Sun decide not to support nested classes... this is getting ugly. --jason On Tuesday 21 May 2002 08:43 am, Justin Casp wrote: Hi List, I've just recently begun to see this error occur sporadically when starting JBoss after being freshly built from the cvs head. I was able to find a build on another machine that's a few days old, and it boots fine. However, when I deploy a user ear on this older build (very simple example from Wrox book) the same error occurs. With the latest cvs code, this error happens when deploying internal Jboss packages (not sure of the terminology). Since it occurs in the scanner thread, I can't undeploy/redeploy the test ear. Any ideas on what may be causing this? I've tried doing a 'build.sh clean' then 'build.sh' but it still happens. Let me know if I can help in tracking this down. I was doing this test ear in order to report another bug, so now I have nested problems. Justin 11:20:13,577 ERROR [MainDeployer] could not start deployment: file:/home/casp/projects/jboss/jboss-all/build/output/jboss-3.1.0alpha/serv er/default/deploy/localobjects.jar java.lang.NullPointerException at org.jboss.util.NestedThrowable$Util.getBoolean(NestedThrowable.java:108) at org.jboss.util.NestedThrowable.clinit(NestedThrowable.java:39) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at org.jboss.util.NestedThrowable$Util.class$(NestedThrowable.java:27) at org.jboss.util.NestedThrowable$Util.clinit(NestedThrowable.java:100) at org.jboss.util.NestedException.init(NestedException.java:50) at org.jboss.deployment.DeploymentException.init(DeploymentException.java:44 ) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartComman d.java:190) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.ja va:84) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java :384) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.jav a:198) at org.jboss.ejb.EntityContainer.startService(EntityContainer.java:360) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198) at org.jboss.ejb.Container.invoke(Container.java:782) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1024) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa tcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy19.start(Unknown Source) at org.jboss.ejb.EjbModule.startService(EjbModule.java:442) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa tcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispa tcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:391) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:693) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:528) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490) at java.lang.reflect.Method.invoke(Native Method)
Re: [JBoss-dev] testsuite crashes vm on linux for cvs-rc3
FYI - I was having a similar problem when I compiled with jdk 1.3, but ran on jdk 1.4 (Windows 2000). -Larry JDK 1.4.0 is also crashing for me about here: [junit] Tests run: 25, Failures: 0, Errors: 1, Time elapsed: 234.215 sec [junit] TEST org.jboss.test.jbossmq.test.SecurityUnitTestCase FAILED # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002D3 # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Server VM (1.4.0-b92 mixed mode) # # An error report file has been saved as hs_err_pid4628.log. # Please refer to the file for further information. # JDK 1.3.1_03 runs fine: tests-unit: BUILD SUCCESSFUL Total time: 5 minutes 5 seconds Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 10, 2002 12:22 AM Subject: [JBoss-dev] testsuite crashes vm on linux for cvs-rc3 Can anyone on linux run the testsuite for cvs-rc3? I have tried several times and it crashes the vm each time under 1.4 (have not yet tried 1.3.1). Seems to happen alot in the jbossmq or jca tests, but I have no idea if that test is tickling the vm or what. My vm seems to be idling around 80 active threads according to ThreadGroup.activeCount() and does not appear to be running out of memory. The process count on the machine maxes out around 200. Yet it crashes each time... why? --jason - This mail sent through IMP: http://horde.org/imp/ ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Branch_3_0 Not Running?
That line in MainDeployer refers to a change I put in 2 days ago. I think you need a clean - or at least you need to recompile the org.jboss.deployment.DeploymentSorter class. -Larry - Original Message - From: Hunter Hillegas [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Tuesday, April 23, 2002 11:00 AM Subject: [JBoss-dev] Branch_3_0 Not Running? I just updated my Branch_3_0 tree and I get this on startup: 10:54:49,833 INFO [MainDeployer] Starting deployment of package: file:/Users/hunter/Unix/Sources/jboss3/build/output/jboss-3.0.0RC1/lib/jboss sx.jar 10:54:49,991 ERROR [Server] start failed java.lang.NoSuchMethodError at org.jboss.deployment.MainDeployer.init(MainDeployer.java:555) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:502) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:190) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:550) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:452) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:320) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:496) Am I doing something wrong or is the build fsck'd? Hunter ___ 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] Work around for ClassLoader deadlock
Is anybody working on this? Any ideas for the implementation? I don't think we can rely on Sun for this fix, and several people have already claimed this to be a show-stopper. -Larry
Re: [JBoss-dev] Workaround for CL stuff
Though I've never experienced this, I think this is the problem scenario: The players: UnifiedClassLoader A (can load directly class foo) UnifiedClassLoader B (can load directly class bar) Thread 1 (context loader is A): Load new class bar: - synchronize on UCL A - Search UCL B - Attempt to synchronize on UCL B Thread 2 (contect loader is B): Load new class foo: - synchronize on UCL B - Search UCL A - Attempt to synchronize on UCL A Can someone verify if this is accurate? -Larry Ok, I am sure we can find something. I would appreciate a brief description of a CL deadlock scenario due to the final loadClassInternal. Jung? Sacha? It's only software, software is dumb marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ 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] [ jboss-Bugs-544848 ] EAR Deployments don't work
This is going to cause other problems. What if I have two wars that uses struts and each have a different version of the same action class because they are different releases of the same web application. If a struts.jar is referred to by a war manifest is should be only loaded by the servlet container class loader. That it is at the war level is just a packaging choice to avoid duplication of the jar in the wars. So how do you recommend this be fixed? The servlet containers do not appear to utilize the Class-Path entry of the war's manifest. I could create a URLClassLoader that loads the war, the WEB-INF/classes and lib, and all manifest entries. It's parent classloader would be a UnifiedClassLoader (perhaps the current thread's context loader?). This again comes back to the fact that the packaging structure should not be the sole dictator of the class loading heirarchy. I agree. I think each deployment type should be able to dictate what url's to expose to the UnifiedClassLoader, and which to keep privately within child URLClassLoaders. A simple hacked solution would be to remove the createClassLoaders from DepoymentInfo, and place that responsibility in the init methods of SubDeployer (with SubDeployerSupport providing the default implementation). I have been looking into a Deployer refactoring anyway... I'll put some time into it this weekend, and present a list of requirements / proposed design for discussion. -Larry Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Larry Sanderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 19, 2002 8:42 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work I'm also running into a problem that may be related to this. I have a .war (or the .war embedded in a .ear properly referenced in application.xml ... OK - A few questions. From where are you accessing this resource (i.e. the location of the directory or jar file where the accessing class lives). Is it in your WEB-INF/lib, WEB-INF/classes, sitting next to the war file? I'm going to assume that it is in the WEB-INF/lib directory, since the only change I made since RC1 would affect nested archives (usually located in WEB-INF/lib). Second question... Have you ever tried this scenario with 3.0 beta, prior to RC1? I am interested to know if that worked. From what I can tell from the class history, I don't think this would have worked, but I may be mistaken. A brief explanation of the classloader hierarchy: JBoss has a custom ClassLoader called the UnifiedClassLoader. ClassLoaders normally have a parent-child hierarchy, such that a child ClassLoader can see all classes loaded by the parent, but the parent cannot see those classes loaded by the child. The UnifiedClassLoader throws that concept out the window. Any class loaded by a UnifiedClassLoader can see every other class loaded by another UnifiedClassLoader, regardless of the parent child relationship. My original changes (in the RC1 release): The problem with war files is that Jetty and Tomcat use their own Classloaders to load up the war file. (This includes the lib and classes directories within WEB-INF). Since they are not using the UnifiedClassLoader, all of JBoss's normal classes can not see any of the files within the web archive. So, if struts.jar was located next to the war file, it would be loaded by JBoss and the UnifiedClassLoader, and when it came time to access your struts Actions (within your war file's lib or classes directories), it would get a ClassNotFoundException. This was the original problem on this thread. My most recent change: Since all classes need to be able to see each other, the obvious solution is to use the UnifiedClassLoader to load all classes. The fix I put in since RC1 was released was to use the UnifiedClassLoader on all nested deployable archives. This is (I think) exactly the way things were done prior to my work. The only problem is that it left out the WEB-INF/classes directory. The fix: I just need to load WEB-INF/classes with a UnifiedClassLoader and your problem should be solved. This is a fairly simple fix, and I will get it in today. I need to create some test cases to check all this, but that will have to wait for the weekend (Is it Friday already?) Sorry for the confusion. -Larry * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13076 ___ 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]
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 ___ 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] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested ejb-jar's and war's should share classes, and it is all based on Class-Path Manifest entries. Technically, per spec, nested archives should never share Classpath's unless there is a Class-Path META-INF entry (i.e. web archives should not, by default, be able to see ejb-jar files within the same ear archive). JBoss takes a more conservative approach, and gives each deployment access to each other's information. This sacrifices archive interoperability for ease of use. The patch I put forward took a middle of the road approach - only those archives specified in application.xml are deployed, but they can all access each others data without Class-Path entries. I like being able to limit the deployments by commenting out portions of my application.xml. I use this all the time when testing within an exploded archive - it allows me to isolate one portion of development. Personally, I don't like the deploy everything philosophy. It just seems sloppy to me. I don't like it within sars, rars, or anything else. There should be a single, definitive, user-specified list of exactly what should be deployed, and when. The idea of: search through every single file within an archive, and check to see if it is deployable leads to hacks like the one currently in MainDeployer: ... unless it is a war file, then let the war deployer figure it out. -Larry Hmmm, I thought that might be what the spec wanted, but when I read it I decided it was consistent with put everything in sight on the classpath since then everything they mention is definitely on the classpath. Maybe we need a configuration switch? What problems come from everything in sight? If you have server-specific jars, you'd need to change the ear anyway to change which are deployed, so why not take out the packages you don't want deployed? Any other thoughts? david jencks On 2002.04.16 17:01:13 -0400 lsanders wrote: It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 ___ 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] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Comments inlined... I agree that there should be a single definitive user-specified list of what should be deployed, but I think it belongs in the ant build file that constructs what gets deployed. To me, it is more sloppy to include stuff in your package that you don't want deployed than to deploy everything in a package. As an example of why this is useful, let me outline my companies development environment: Our cvs repository is itself an exploded ear file, plus an src directory, the ant build scripts, minus any compiled code. We have 3 war archives, and a single ejb-jar file. The ant scripts simply compile the appropriate source files to the propper directories (WEB-INF/classes, the ejb-jar, etc...). In development, this directory is directly deployed by JBoss. Another ant task builds the compressed archives for production (stripping out the src, build scripts, etc...), but development is done directly within the deployed application. This has improved the speed of developing / redeploying / testing dramatically. (Perhaps this gives you an idea why I have been so hung up on exploded deployment ;-) ) To remove an archive from our deployment would meen removing an entire CVS directory. The original motivation behind the unified classloader was to make it practical to work on giant applications that are manageable only if they are packed into multiple ears, but which need to refer to each other's classes, and which need to be independently redeployable. A tree-based classloader scheme isn't going to work for this. I'm not suggesting getting rid of this. In fact, I like the convenience of not specifying Class-Path entries all over my META-INF files, and I think the spec should allow shared classpaths. But, it should be recognized that any user who makes use of this feature may need to make some configuration changes if they switch app servers. I have never understood what the purpose of the classpath entries inside an ear really was, nor the problems with deploying everything in sight. It just takes control away from the user, though it could be argued that the user doesn't have to include things she does not want deployed. To me, your problem seems like it is based on your convenience and way of working rather than an intrinsic problem with everything. I could be missing something, please let me know what. No, my problem is with an app-server making assumptions that a user may not want. Further, the user has no way of overriding these assumptions. Put simply: JBoss is violating the J2EE specification here. Consider the following, legal ear archive: 2 nested war files, who use the same web-context, but only the first specified in application.xml. JBoss will not be able to deploy this because of the context root conflict, however a compliant app server would. Also, we still need to deploy every .sar inside a j2ee package unless we want to add a jboss-specific dd to every package indicating which sars get deployed. I think adding a dd just for this is silly. Yeah, a bit silly, but IMO better than what we have now. I would prefer a documented convention stating what directory within a sar archive nested deployments should live. The same goes for rar files. (Kind of like war files - they have the WEB-INF/lib and WEB-INF/classes directories). Did you change the behavior of deploying sars or are all of them still deployed? No - I got yelled at when I tried :-) Everything works exactly as it did, except the EARDeployer, and I will submit a patch to revert this functionality if required. Anyway for ears I guess looking at application.xml should be ok since the user has to include it anyway. Sorry for rambling, and I hope I'm not coming off too strongly. Thanks for listening! -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cvs lock
I'm having trouble with the cvs repository. It is reporting a cvs lock in /cvsroot/jboss/manual/src/metadata. Is there anything I can do to fix this? -Larry
