Re: [JBoss-user] spam
I don't suppose we could make this list postable by subscribers only? Cheers Geoff - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 25, 2002 11:59 PM Subject: [JBoss-user] »¶Ó¹âÁÙÉÁµç½ðÈÚͶ×ÊÔ¤²âÍø > ¸÷λÍøÓÑ´ó¼ÒºÃ£º > Çë×ÐϸÔĶÁÒÔÏÂÐÅÏ¢£¬ÄãÖ»ÓÐÄÜÊÕµ½Ò»´Î°¡£¡Èç¹ûÄã¸Ð¾õÏÂÃæµÄÐÅÏ¢¶ÔÄãûÓÐÓô¦£¬ÎÒ ºÜ±§Ç¸£¬ÇëÄúɾ³ý¡£Ð»Ð»£¡£¡ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] connection pooling and jboss.jcml
Hi there,
given that particular configuration using:
ConnectionPoolDataSource cpds =
(ConnectionPoolDataSource)ctx.lookup("java:/PostgresDS");
should obtaining a connection to your database.
To find out what is bound where, you can connect to port 8082 on the
host running JBoss to access the JMX based html interface to JBoss
configuration. In particular, have a look for 'service=JNDIView' under
'DefaultDomain'. From there you can 'list' all bound resources to see
what is where.
Hope this helps.
Geoff
Kotamraju, Srinivas, BmS- NY1540 wrote:
> hi all,
> I am trying to configure jboss.jcml to create a connection pool and work
> with my postgres database..
> my question is what will be the context.lookup JNDI Name for the connection?
> ConnectionPoolDataSource cpds =
> (ConnectionPoolDataSource)ctx.lookup("??");
> or, If this is not the procedure can someone please post the procedure for
> creating a connection pool.
> thanks
>
> .
> name="DefaultDomain:service=XADataSource,name=PostgresDB">
>name="DataSourceClass">org.opentools.minerva.jdbc.xa.wrapper.XADataSourceImp
> l
> PostgresDS
> jdbc:postgresql://localhost:5432/dev
> post
> post123
>
>
> code to get the connection:
>
> public static Connection getConnection() {
>
> Connection conn=null;
> try {
> // initialize JNDI lookup parameters
> Context ctx = ManualJNDI.getInitialContext();
> System.out.println("got context");
> ConnectionPoolDataSource cpds =
> (ConnectionPoolDataSource)ctx.lookup("");
> System.out.println("got datasource");
>
> PooledConnection pc = cpds.getPooledConnection();
> System.out.println("got pooledconnection");
> conn = pc.getConnection();
> System.out.println("got connection1");
>
> }
> catch(Exception exception){
> exception.printStackTrace();
> }
> finally{
> return conn;
> }
> }
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Does anybody Configure jboss for MS JDBC Driver ??
You need to set a property on the database driver: SelectMethod=Cursor. Search this list or look on the forums for sample configurations. I posted one not long ago. - Geoffrey : -Original Message- : From: David Cao [mailto:[EMAIL PROTECTED]] : Sent: Monday, December 17, 2001 10:07 PM : To: JBoss 2 : Subject: [JBoss-user] Does anybody Configure jboss for MS : JDBC Driver ?? : : : Does anybody successful use MS JDBC driver with jboss ? I set up with : it, but it always see it can't create prepared statement, does anybody : can forward my a sample configuration? : : Thanks, David : : ___ : JBoss-user mailing list : [EMAIL PROTECTED] : https://lists.sourceforge.net/lists/listinfo/jboss-user : : _ : This message has been checked for all known viruses by the : MessageLabs Virus Scanning Service. For further information visit : http://www.messagelabs.com/stats.asp : _ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Isn't difficult to change database from MS SQL Server to My SQL or PostgreSQL??
Yes, the MS driver will work with JBoss. What problem are you having? Here's the configuration I'm using: myPoolName org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl jdbc:microsoft:sqlserver://myServer:1433;DatabaseName=myDatabase; SelectMethod=cursor myUser myPassword CC-ing this to the list for people who might search the archive for this issue. - Geoffrey : -Original Message- : From: David Cao [mailto:[EMAIL PROTECTED]] : Sent: Thursday, December 13, 2001 2:05 PM : To: [EMAIL PROTECTED] : Subject: RE: [JBoss-user] Isn't difficult to change database : from MS SQL : Server to My SQL or PostgreSQL?? : : : Thanks for your reply, so what type of free JDBC driver you are using : now? can you give me a download URL? I tried MS JDBC driver, but it : won't work with Jboss, if you make it work, it will be great : help for me : if can you forward me the configuration ? : : Thanks a lot. I appreciate your help : David : : -Original Message- : From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] : Sent: Thursday, December 13, 2001 8:38 AM : To: David Cao : Subject: RE: [JBoss-user] Isn't difficult to change database : from MS SQL : Server to My SQL or PostgreSQL?? : : : Don't know about a hosting company, but JBoss w/ Microsoft SQL Server : works : fine for us, both 7.0 and 2000, using the free Microsoft (or Merant, : depending on how you look at it) SQL Server JDBC driver, as well as : other : drivers. Shouldn't be an issue. : : - Geoffrey : : : -Original Message- : : From: David Cao [mailto:[EMAIL PROTECTED]] : : Sent: Monday, December 10, 2001 7:58 PM : : To: [EMAIL PROTECTED] : : Subject: [JBoss-user] Isn't difficult to change database from MS SQL : : Server to My SQL or PostgreSQL?? : : : : : : We have some program running use MS SQL, but it's much easier : : to find a : : hosting company support MySQL+Jboss or PostgreSQL+Jboss than : : SQLServer+Jboss, so does any body make this type of change : : before? How : : much work it is? (We still need us SQL Server internally for : : development) : : : : Thanks : : David : : : : -Original Message- : : From: David Jencks [mailto:[EMAIL PROTECTED]] : : Sent: Monday, December 10, 2001 4:37 PM : : To: Jason Dillon : : Cc: [EMAIL PROTECTED] : : Subject: Re: [JBoss-dev] should J2eeDeployer extend : : DeployerMBeanSupport? : : : : : : On 2001.12.10 18:42:23 -0500 Jason Dillon wrote: : : > > Universal deployer is asked to deploy a package. : : > : : > =) : : > : : > > It starts by unpacking all the nested jars (recursively) and : : locating : : > all : : > > the deployment descriptors (this functionality is pretty much in : : > > DeployerMBeanSupport today). (there may be some needs to : : ignore some : : > dd's, : : > > per j2ee spec. I'm still looking) : : > > : : > > It then collects related deployment descriptors (such as : : ejb-jar.xml, : : > > jboss.xml, and jbosscmp.xml) and uses xslt to combine : : them into one : : > jboss : : > > specific dd that includes all relevant info (this may include : : expanding : : > > defaults to be present wherever they are used). (I've prototyped : : this, : : > its : : > > pretty easy. The ability to deploy from such a single : dd has been : : > > requested). : : > : : > Would this allow users to override specific parts of an ejb config : : > perhaps? : : > Say to just set (or unset) the default RMI port, or up : the number of : : > threads : : > that a MDB is allocated? : : > : : > > One of the features of the combined dd is that everything is an : : mbean : : > > configuration. Therefore, there are no more standalone : "deployer" : : > mbeans. : : > > Instead, an mbean that represents the deployed unit is : : created, and : : is : : > > responsible for interpreting the dd xml itself. As a : side effect, : : > Andreas : : > > gets appropriately named mbeans for each deployment : unit, that can : : > create : : > > his jsr-77 mbeans to proxy themselves. : : > : : > Will these beans have controls to allow them to be undeployed or : : changed : : > at : : > runtime too? : : > : : > How will new deployment types be handled? How does the universal : : > deployer : : > know what type of deployer mbean to create for the requested : : deployment : : > unit? : : : : What I was thinking of was actually to use xslt to : transform all dd's : : into : : our mbean config language, and use ServiceDeployer to deploy the : : resulting : : file. The "deployment" mbeans are than pretty much like any : : other mbean : : to : : the core system. If you think of something else that needs : deploying, : : you : : just write a deployment mbean for it and possibly some xslt : scripts to : : get : : the dd into a canonical form. : : : : david jencks : : > : : > Sounds like you might need a DeployerFactory, which despenses : : Deployers : : > for : : > the UniveralDeployer. Or I guess the UD could also be a DF...
RE: [JBoss-user] RE: contributing an app
Depending on the app, and particularly if it's issue tracking (as was previously mentionned), I might well be interested in contributing. This is getting fairly OT for the JBoss list, though, and I haven't been on this list long enough to know how that's viewed. - Geoffrey : -Original Message- : From: Peter Shillan [mailto:[EMAIL PROTECTED]] : Sent: Tuesday, December 04, 2001 5:25 AM : To: [EMAIL PROTECTED] : Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] : Subject: [JBoss-user] RE: contributing an app : : : Hi Guys, : : I would like to help produce such an application. I have experience in : most of the bullet points mentioned below. : : Let me know (*please*) if I can be of help. : : Peter. : : -Original Message- : Hello, : : * Hicks, James <[EMAIL PROTECTED]> [011204 03:37]: : > featured application that runs with JBoss. If anyone has any ideas : for an : > application, let me know. I am currently working on an affiliate : tracking : > system, I could GPL it and use it for the project. Anyone want to : work on : > this? : : I do! I almost don't mind on the basic features. : : I'd like to see an open source/free software J2EEE application made : with, randomly: : : - JBoss : - using JAAS for security roles and capabilities : - JMX-based backoffice : - CMP 2.0 whenever possible : - a MVC pattern for user interface production with XML/XSL (Struts?) : - Cocoon for XML processing, if appropriate : - SOAP-based access available for B2B service access : - Log4J for program auditing : - JUnit and related testing frameworks : - J2EE design patterns as those explained in Sun's future book : - aspectj for aspect programming : - ant for build : - xdoclet for deployment descriptor and interface generation : - ready for the ASP model : - made using an open-source/free software J2EE/EJB application : framework, or delivering one as an outcome : : What do you think? Have you people made a commercial/open source/free : software product like this one? : : Cheers, : : -Sylvan : : : __ : __ : : E-mail is an informal method of communication and may be : subject to data corruption, interception and unauthorised : amendment for which Digital Bridges Ltd will accept no : liability. Therefore, it will normally be inappropriate to : rely on information contained on e-mail without obtaining : written confirmation. : : This e-mail may contain confidential and/or privileged : information. If you are not the intended recipient (or have : received this e-mail in error) please notify the sender : immediately and destroy this e-mail. Any unauthorized : copying, disclosure or distribution of the material in this : e-mail is strictly forbidden. : : __ : __ : : : ___ : JBoss-user mailing list : [EMAIL PROTECTED] : https://lists.sourceforge.net/lists/listinfo/jboss-user : : _ : This message has been checked for all known viruses by the : MessageLabs Virus Scanning Service. For further information visit : http://www.messagelabs.com/stats.asp : _ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
~RE: [JBoss-user] Packaging
Okay, thanks. And in order to test that I've succeeded, is there any way that I can verify that I'm using the optimized stack, vs. not, from JBoss console, log files, or programatically? I'm probably going to experiment with getClass( ).getClassLoader( ) to see if I can figure that out, but if anyone already has an answer to the question, I'm certainly open to hear it. - Geoffrey : -Original Message- : From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] : Sent: Monday, December 03, 2001 11:48 AM : To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] : Subject: RE: [JBoss-user] Packaging : : : This is caused by jasper invocation of javac. Javac is invoked with a : command line classpath option, which only includes the : classes in the war. : They way you fix it is to include your : application-ejb-client.jar in both : places. You MUST set the manifest.mf classpath option to load the : application-ejb-client.jar from the ear. This way jasper can find the : classes for compiling and JBoss loads the classes from the common jar, : enabling the optimized stack. : : So the short answer is do both. : : -dain : : > -Original Message- : > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] : > Sent: Monday, December 03, 2001 9:51 AM : > To: [EMAIL PROTECTED] : > Subject: [JBoss-user] Packaging : > : > : > No response to my last email, let me try to simplify the question. : > : > If I package the ear this way: : > : > application.ear : > +application.war : > +application-ejb-client.jar (ejb client interfaces, : > and common : > classes) : > +(everything else, the servlets, web.xml, JSPs, etc, : > filed in their : > locations) : > +application-ejb.jar : > +META-INF : > +MANIFEST.MF : > +application.xml : > : > This works fine under JBoss/Tomcat, JBoss/Catalina and : > JBoss/Jetty. But : > it's slow, and I'm told this is a packaging issue--I'm not : getting the : > optimized stack. If I repackage the ear this way: : > : > application.ear : > +application.war (no client jar) : > +application-ejb.jar : > +META-INF : > +MANIFEST.MF : > +application.xml : > : > This works fine under JBoss/Catalina, and seems markedly : > faster, but any JSP : > page in JBoss/Tomcat (3.2.3) or JBoss/Jetty can't find common : > classes and : > EJB interfaces, apparently due to a Jasper bug with the : class-loader. : > : > So is there a way to package my EAR that will work under : > JBoss/Jetty and : > JBoss/Tomcat, but still be speedy, using the optimized stack? : > : > Thanks, : > : > - Geoffrey : > : > __ : > Geoffrey Wiseman: Internet Applications Manager : > Medium One : > t. 416.977.2101 x. 529 : > http://www.mediumone.com/ : > __ : > Think it. Build it. Work it. : > : > : > : > : _ : > This message has been checked for all known viruses by the : > MessageLabs Virus Scanning Service. For further information visit : > http://www.messagelabs.com/stats.asp : > : > : > ___ : > JBoss-user mailing list : > [EMAIL PROTECTED] : > https://lists.sourceforge.net/lists/listinfo/jboss-user : > : : _ : This message has been checked for all known viruses by the : MessageLabs Virus Scanning Service. For further information visit : http://www.messagelabs.com/stats.asp : _ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Packaging
No response to my last email, let me try to simplify the question. If I package the ear this way: application.ear +application.war +application-ejb-client.jar (ejb client interfaces, and common classes) +(everything else, the servlets, web.xml, JSPs, etc, filed in their locations) +application-ejb.jar +META-INF +MANIFEST.MF +application.xml This works fine under JBoss/Tomcat, JBoss/Catalina and JBoss/Jetty. But it's slow, and I'm told this is a packaging issue--I'm not getting the optimized stack. If I repackage the ear this way: application.ear +application.war (no client jar) +application-ejb.jar +META-INF +MANIFEST.MF +application.xml This works fine under JBoss/Catalina, and seems markedly faster, but any JSP page in JBoss/Tomcat (3.2.3) or JBoss/Jetty can't find common classes and EJB interfaces, apparently due to a Jasper bug with the class-loader. So is there a way to package my EAR that will work under JBoss/Jetty and JBoss/Tomcat, but still be speedy, using the optimized stack? Thanks, - Geoffrey __ Geoffrey Wiseman: Internet Applications Manager Medium One t. 416.977.2101 x. 529 http://www.mediumone.com/ __ Think it. Build it. Work it. _ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Packaging - Optimized vs. Not (or Tomcat 4.0 SSL)
Trying to get this resolved is turning out to be more problematic than expected. I'm left with several questions: - Does anyone yet have a solution for JBoss/Catalina (Tomcat 4) with SSL? Searches on the list indicate that other people have had problems, but no solutions that I could see. - Is there any way I can tell if I'm running in the optimized in-vm stack vs, not, other than by the performance that I'm getting? It'd be nice to be able to verify, and quite possibly even include it in the unit tests, if that's do-able. - What structure should I be using to package my EAR for JBoss/Tomcat or JBoss/Jetty? The reasons for these questions follow. After developing a few basic servlets and ejbs, and verifying they worked together under JBoss/Tomcat, we found that we couldn't use the EJBs in JSPs. Some searching on the list at the time led to advice to basically include the bean jar (or at least the interfaces) in the WAR. (cf.: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg12474.html ). We put the entire EJB jar into the WAR for the time being, and left it there. That may not have been the best of decisions, but it's what we did. It worked, and we moved on. Based on the feedback I got WRT performance issues, I tried removing the EJB JAR again. It worked just fine under JBoss/Tomcat4, and performance seemed much improved. Before I could get into really heavily performance-testing that, we ran into other problems. Unfortunately, we also need SSL working for this stage of the application, and two of my co-workers spent time trying to get SSL working with JBoss/Tomcat4, and failed. Unless we can get that working, That left us with JBoss/Tomcat 3.2.3 or JBoss/Jetty. JBoss/Tomcat 3.2.3 suffers from the JSP bug listed above, as does (it seems) Jetty. I don't know much about Jetty yet, but it seems to make use of Jasper, and it seems to be the version of Jasper that has the classloading issue. I've now re-modified our build process to include a client version of the EJB jar (minus the beans and the ejb-jar.xml), and I'm testing that a little, but I'm assuming that this will give us the non-optimized stack issues that we've been having, and thus poor performance. So, is there a way that I can get the optimized stack working with JBoss/Tomcat 3.2.3 or JBoss/Jetty, and if so, can someone point me in the right direction? If it's a packaging issue, how should I be packaging it? Or is there a way to get JBoss/Tomcat4 working with SSL? And, short of load testing the application, is there any way for me to tell if the application is running 'optimized' vs. not, since clearly I can end up running 'not' by my package structure? Sorry for the rather large list of questions. I've been scrolling through the list archive for a day and a bit now, and getting relatively nowhere. Even pointer to threads in the mail archive that might be more helpful than what I've been looking at will be happily accepted. - Geoffrey __ Geoffrey Wiseman: Internet Applications Manager Medium One t. 416.977.2101 x. 529 http://www.mediumone.com/ __ Think it. Build it. Work it. _ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Redux of Performance Issues
Allright, I'm happy to hear that I'm probably running it not-optimized, and the 'factor of 10' would certainly make me a lot happier, if that's what's happening. Some prelimary changes indicate that you're probably right. There's a significant decrease in processor load already, and at the moment, Tomcat is definitely holding JBoss back. We're probably going to give Jetty a shot in the short term, and find out what, if anything, we can do about getting Tomcat to handle the load. So, it looks like packaging was indeed the problem. Where that leaves us, we don't yet know. We'll do some tests and see what the results are, but the JBoss performance leapt from "just plain silly" to "uh, let's see what we can do about tomcat" in short order, so it's immediately promising. Thanks. I'll let you know when I know more. - Geoffrey : -Original Message- : From: marc fleury [mailto:[EMAIL PROTECTED]] : Sent: Tuesday, November 27, 2001 3:54 PM : To: David Jencks; [EMAIL PROTECTED] : Subject: RE: [JBoss-user] Redux of Performance Issues : : : Ok the point is that a factor of 10 or so is indicative of a : non-optimized : run and thus a poor packaging that trip the classloaders. : : The poor setup comes from confusion in the classes in the war : and ear or : duplication of the classes and what not. Just the simple : test you mention : david runs 10 times faster. : : BTW the line I was talking in the ContainerInvoker that I : removed for JBoss : 3.0 is the one that is making his tests fail and I wanted to : remove it for : _exactly_ this reason. : : Guys setup the supposedly integrated stacks, then the classes : are not the : same in teh different classloaders or are not present in the : EJB package or : go figure what he runs and it runs non-optimized as a result. : : Bottom line he trolls crying about performance. (no offense : man we just had : this discussion on why this particular category of problem : appears). So next : he will see "classcast exception" and won't worry about perf. : : Then running Resin outside stack is just the non-optimized : run and tells you : exactly what you need to know :) that the throughput when you : serialize : everything is 25 (minor gain over NON optimized tomcat). : : If the throughput was optimized you would see at least a factor of ten : depending on the payload of his invocations which seems heavy : anyhow hence a : real native pointer stack would run above that. : : Are we clear? the goal is get the classes PACKAGING right, : make sure the : classes you reference are the one and same : : marcf : : PS: Also david you can see that advanced classloaders here : would really : help, we would get rid of this packaging nightmare and : non-sense once and : for all. THIS CLASS OF PROBLEM WOULD BE GONE, NO USER : LIBERTY TO SCREW IT. : To be honest I am not even sure I know on the top of my head : how to package : the stuff sure-fire so that you run always invm and since : that test masks : the problem he is fucked, he can't tell easily as we silently run with : un=proper package. Let the engine blow. Running Resin is : also brain-dead : he is always running out of VM. Also here Orion uses the : same classloaders : when running INVM through and through hence running optimized : even if the : packaging is funky, we don't have that luxury today due to 3rd party : integration that will be gone with the above and/or : integration of stacks cl : ala jetty. Bottom line the simplest in this case is to run : 1- good package : 2- same package on forthcoming 3.0 :) : : : : : |-Original Message- : |From: [EMAIL PROTECTED] : |[mailto:[EMAIL PROTECTED]]On Behalf Of : David Jencks : |Sent: Tuesday, November 27, 2001 3:13 PM : |To: [EMAIL PROTECTED] : |Subject: Re: [JBoss-user] Redux of Performance Issues : | : | : |I haven't looked on the forums in a day or two, so I'm not : sure if you've : |asked there as well. You may get more response. : | : |Have you run the testsuite and made sure it runs at a : reasonable speed (= : |very fast;-)? I'm mostly familiar with the 3.0 testsuite, : but I would : |start by running multithreaded tests like banktest with hypersonic : |datasource and your production datasource. Try with : different numbers of : |threads-- I think in 2.4.x you have to go inside the tests and change : |hardcoded numbers. I'm not sure where there is comparison : info, but if you : |get numbers that seem slow ask. If they are slow, there's : something wrong : |with your setup. If they are fast, then there may be : something wrong with : |your app or tomcat integration or ???. But start simple. : | : |david jencks : | : |On 2001.11.27 14:09:15 -0500 [EMAIL PROTECTED] wrote: : |> For reasons unknown, this message hasn't been going out to : the list. : |> Trying : |> again. : |> : |> -- : |> : |> Okay, I've clearly managed to piss off a few people by my : concerns about : |> JBoss performance. : |> : |> Let m
RE: [JBoss-user] Redux of Performance Issues
I'm not at all sure what you're saying. If you're suggesting that I need to use the integrated JBoss/Tomcat product that I can download, I /am/. If you're suggesting something else, then could you clarify, because I really don't get what you just said. I have JBoss/Tomcat installed and running. Is there something else you wanted me to do? - Geoffrey : -Original Message- : From: marc fleury [mailto:[EMAIL PROTECTED]] : Sent: Tuesday, November 27, 2001 2:34 PM : To: [EMAIL PROTECTED]; [EMAIL PROTECTED] : Subject: RE: [JBoss-user] Redux of Performance Issues : : : look dude, : : get the integrated jboss-tomcat stack you are running : non-optimized out of : stack, period. : : come back when you have set it up, or don't we don't care, : : marcf : : |-Original Message- : |From: [EMAIL PROTECTED] : |[mailto:[EMAIL PROTECTED]]On Behalf Of : |[EMAIL PROTECTED] : |Sent: Tuesday, November 27, 2001 2:09 PM : |To: [EMAIL PROTECTED] : |Subject: [JBoss-user] Redux of Performance Issues : | : | : |For reasons unknown, this message hasn't been going out to the : |list. Trying : |again. : | : |-- : | : |Okay, I've clearly managed to piss off a few people by my : concerns about : |JBoss performance. : | : |Let me start out by saying that I'd be more than happy to get my : |application : |working speedily under JBoss. Orion's documentation is poor : at best, and : |JBoss is fully open-source. I have a great deal of respect : for some of : |JBoss's technology (the verifier and deployer are probably : the best I've : |seen), and where it's coming from. I chose JBoss for the initial : |development because of its reputation and my own interests. : | : |That said, if the performance I'm getting out of JBoss is : the best I can : |expect, or, at least, the best I can manage to get, then I : |absolutely cannot : |use it. Not because I think it 'sucks rocks', because it : doesn't, but : |simply because it will not support the user load I need it to in : |any sort of : |cost-effective manner. Some of you would probably be just : as happy to see : |me go somewhere else, from the tone of your emails, but I'd : personally : |rather find a way to get the performance out of JBoss, for : this or other : |projects. : | : |And, ultimately, it seems as if the performance I'm asking for is : |relatively : |reasonable. I expect a certain amount of overhead in EJB : performance, and : |I'm not asking to duplicate the speed of a bean-only : implementation. But : |supporting a maximum of 25 concurrent users on a decent (if : not maxed-out) : |server seems ... suspiciously slow. : | : |It may be that I've missed some settings to speed things up. It : |may be that : |our application's architecture is better suited to Orion : than to JBoss. : |Whatever it is, I'd like to find out. So I've joined the : JBoss list, and : |I'm here to ask some questions. I'm not trying to promote : Orion, or insult : |JBoss. I like bits of both of them, and the reasons for : that, I can get : |into another day. Ultimately, however, I'd rather support : JBoss as an : |open-source appserver, if I can. : | : |-- : | : |Now, on to the details. Some of you pointed out, and : rightly so, that I : |hadn't provided much in the way of details of what I've : tried, which is : |true. I wanted to start off by finding out if the kind of : numbers I was : |talking about seemed realistic or not, based on the : experience of people : |who'd spent more time with JBoss than I have, but it's : probably fair to say : |that you couldn't really say without knowing a lot more about my : |application. So let's get into a few details. : | : |Let's start with versions. I did some of my original EJB : |experimentation on : |JBoss-2.4.1. We started developing a project on : JBoss-2.4.1a w/ Embedded : |Tomcat, which was the latest JBoss/Tomcat grouping at the : time. We started : |noticing performance concerns then. When Tomcat 4 came out, : we moved to : |JBoss-2.4.3 w/ Embedded Catalina, so that we could try a few : things, and : |found it not to be slower, so we stayed with it. : | : |After we reached a point where we needed to see better : performance, we did : |some optimizing of our app with a profiler, and tried JBoss : 2.4.3 w/ Resin, : |which we already knew to be fast. That gave us a minor speed : |boost, but not : |very much, leading me to believe that JBoss might be the : cause of some of : |our performance. By comparison, Orion 1.5.2 seems to be : very much faster. : | : |All of this is running on Windows 2000. The versions of : Tomcat are 3.2.3 : |and 4.0, as far as I know. The version of Resin is the latest : |version as of : |a few weeks ago, I'd have to go check. If it's important, I will. : | : |Processor speed depended, but developers are working, largely, on : |PIII-700MHzs, and we did most of our load-testing on a Ghz P4. : | : |Tuned updates are on, jaws debug is off, and logging was s
[JBoss-user] Redux of Performance Issues
For reasons unknown, this message hasn't been going out to the list. Trying again. -- Okay, I've clearly managed to piss off a few people by my concerns about JBoss performance. Let me start out by saying that I'd be more than happy to get my application working speedily under JBoss. Orion's documentation is poor at best, and JBoss is fully open-source. I have a great deal of respect for some of JBoss's technology (the verifier and deployer are probably the best I've seen), and where it's coming from. I chose JBoss for the initial development because of its reputation and my own interests. That said, if the performance I'm getting out of JBoss is the best I can expect, or, at least, the best I can manage to get, then I absolutely cannot use it. Not because I think it 'sucks rocks', because it doesn't, but simply because it will not support the user load I need it to in any sort of cost-effective manner. Some of you would probably be just as happy to see me go somewhere else, from the tone of your emails, but I'd personally rather find a way to get the performance out of JBoss, for this or other projects. And, ultimately, it seems as if the performance I'm asking for is relatively reasonable. I expect a certain amount of overhead in EJB performance, and I'm not asking to duplicate the speed of a bean-only implementation. But supporting a maximum of 25 concurrent users on a decent (if not maxed-out) server seems ... suspiciously slow. It may be that I've missed some settings to speed things up. It may be that our application's architecture is better suited to Orion than to JBoss. Whatever it is, I'd like to find out. So I've joined the JBoss list, and I'm here to ask some questions. I'm not trying to promote Orion, or insult JBoss. I like bits of both of them, and the reasons for that, I can get into another day. Ultimately, however, I'd rather support JBoss as an open-source appserver, if I can. -- Now, on to the details. Some of you pointed out, and rightly so, that I hadn't provided much in the way of details of what I've tried, which is true. I wanted to start off by finding out if the kind of numbers I was talking about seemed realistic or not, based on the experience of people who'd spent more time with JBoss than I have, but it's probably fair to say that you couldn't really say without knowing a lot more about my application. So let's get into a few details. Let's start with versions. I did some of my original EJB experimentation on JBoss-2.4.1. We started developing a project on JBoss-2.4.1a w/ Embedded Tomcat, which was the latest JBoss/Tomcat grouping at the time. We started noticing performance concerns then. When Tomcat 4 came out, we moved to JBoss-2.4.3 w/ Embedded Catalina, so that we could try a few things, and found it not to be slower, so we stayed with it. After we reached a point where we needed to see better performance, we did some optimizing of our app with a profiler, and tried JBoss 2.4.3 w/ Resin, which we already knew to be fast. That gave us a minor speed boost, but not very much, leading me to believe that JBoss might be the cause of some of our performance. By comparison, Orion 1.5.2 seems to be very much faster. All of this is running on Windows 2000. The versions of Tomcat are 3.2.3 and 4.0, as far as I know. The version of Resin is the latest version as of a few weeks ago, I'd have to go check. If it's important, I will. Processor speed depended, but developers are working, largely, on PIII-700MHzs, and we did most of our load-testing on a Ghz P4. Tuned updates are on, jaws debug is off, and logging was set as low as we really could expect it to be. Our performance numbers were derived in several ways - by using the Microsoft Web Application Stress tool (since we've used that in the past, and haven't yet found a better alternative; if you have suggestions, I'm happy to hear them), watching memory/processor load on the box being tested, junit test times and subjective experience. Our initial concerns came out of JUnit test times. Our EJB tests (which are pretty thorough, I'll admit) are taking several seconds, whereas the time required to test a hand-rolled bean solution was usually well, well under a second. HttpUnit tests are taking tens of seconds, instead of seconds. This began to concern me, but we didn't need performance at an early stage, and I knew I could replace Tomcat and/or JBoss if necessary. Once we started to use the Web Application Stress Tool, though, we started to get really concerned. After some profiling to speed a few things up, we were unable to get more than about 20 simultaneous users on the application without slowing things down significantly, getting Time To Last Byte on some of the more intense pages up past ten seconds, which is far too long. Even running Resin and JBoss together was getting us only up to 25. The processor usage on the server while the load test was running was practically solid at 10
[JBoss-user] JBoss vs. Orion - Thoughts
I mentioned in my last email that I like bits of both Orion and JBoss, but didn't want to go into detail in that message because it really didn't have a lot to do with the performance issues. Let me note a few points: Pro-Jboss: - Open Source. That's a big factor. I like the general concept, and I like to know that I can go to the source if I have specific issues. We've already done that to solve an error message here or there. - The verifier and deployer is top-notch. Great, clean error messages, and consistent deployment. Issues that arose under pure Tomcat development never surfaced under JBoss/Tomcat, and the deployer/verifier seemed to be a part of that. - The lists and forums are busy, and often helpful. Pro-Orion: - I like the fact that almost all of the configuration files mirror J2EE configuration files. Where JBoss puts EJB JNDI names in jboss.xml and ejb persistence information in jaws.xml, Orion simply has their app-server specific EJB information in orion-ejb-jar.xml, and their orion application information in orion-application.xml, and so on. It's clean, clear, and understandable. - It's really, really fast. - It has a lot of little neat features, most of which are orion-specific, and thus not portable. Con-JBoss - Occasional error messages turned into null pointer exceptions, and we had to track down a few issues into source this way. One or two of them cost us over a day of development time. - We are currently experiencing performance problems. Con-Orion - The documentation is sparse, confusing, and generally hard-to-absorb. Some areas have no documentation to speak of. - The error messages could, sometimes, use a great deal of work. I've had to work out problems the 'hard way' more than once. - The deployment process does not over-write several of the files it unbundles, forcing you to delete these by hand. They have their reasons, but I much prefer the JBoss model. - It's not open source. If I have an issue and no-one knows what's causing it, I can't track it down myself. At all. - Geoffrey __ Geoffrey Wiseman: Internet Applications Manager Medium One t. 416.977.2101 x. 529 http://www.mediumone.com/ __ Think it. Build it. Work it. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] JMS Performance / Persistence
All, First post, so apolgies if this is a repeated topic, i have checked the archives without much luck so here's hoping its new. I am experimenting using the JBossMQ implementation for a new project and am having some serious performance problems. Our system will be receiving (bytes) messages on multiple queues (MQSeries queues infact) and we will have a de-queuing engine that persists these messages to an oracle database before repackaging them as object messages on a topic. I don't believe this framework is anything unusual. Our problem is volume, we are expecting to receive near 50 messages from various MQ-Series queues a day, which will be picked up and placed onto the JBossMQ Topic, so i have written a series of utilities to test how well the application service can cope with such volumes. Posting 1 bytes messages to a JBossMQ Q has typically taken in the region of 1 minute, our engine can persist these and post them onto a topic at a rate of around 1000 / minute which is acceptable. However once we add subscribers to the topic we find that for performance drops by around 50%. Posting the original 1 messages takes no longer, but the throughput for posting to the topic and subsequently reading from the topic is now greatly reduced. FYI, both the engine and the subscriber are using a messagelistener to "poll" for new messages... I have noticed the queue / topic dat files in the /db/jmsmq directory grow rapidly and that the persistence is all file based, which is where i think the depreciation of speed lies. Am i right in assuming the queues and topics write messages to the file and then requests for these messages trawl the files for outstanding messages? I know it is possible to point commercial JMS-MQ implementations at a database to use instead of a file-based persistence which i assume would improve speed greatly. Can this be done with JBoss at present? Am i missing something glaringly obvious? I really want to prove open-source is the way forward for the app-server in this project so comments, help, support are encouraged :) Regards Geoff -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
