Re: TranQL issue at SPECjAppServer2004 atomicity tests
It looks to me as if a local-tx only connector is being used as if it
supports xa. It shouldn't be possible to deploy a connector with a
correct ra.xml in such a way as to create this problem. Can you
supply the geronimo plan for the connector, and indicate which
connector you deployed, and exactly how you deployed it? With this
information figuring out what is wrong and how to fix it should be
easy (famous last words :-)
Many thanks,
david jencks
On Apr 8, 2006, at 2:10 PM, Zakharov, Vasily M wrote:
Hi, all,
I've successfuly deployed SPECjAppServer2004 benchmark on Geronimo 1.0
(see http://issues.apache.org/jira/browse/GERONIMO-1800), but I have
trouble running the basic atomicity tests
(http://localhost:8080/SPECjAppServer/ page, link "Atomicity Tests")
that check the correctness of the benchmark operation - all three
tests
are marked FAILED.
The investigation (see below) showed that the root cause for the
problem
is the following piece of code:
org.tranql.connector.jdbc.ManagedJDBCConnection:
123 public XAResource getXAResource() throws ResourceException {
124 throw new NotSupportedException("XAResource not available
from
a LocalTransaction connection");
125 }
The question is, how critical this situation is? Does it mean
SPECjAppServer2004 uses things it shouldn't use? Or the problem
lies in
TranQL implementation, or maybe Derby database or Derby JDBC
driver? Or
does it mean SPECjAppServer2004 can't run on Geronimo at all?
Any ideas, suggestion and comments are highly welcome!
Thanks!
Here's the original stack displayed in Geronimo console window at each
atomicity tests' run:
javax.transaction.TransactionRolledbackException:
javax.ejb.FinderException: Error executing statement: SELECT C.C_ID
FROM
C_CUSTOMER C WHERE C.C_ID = ?
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke
(ContainerPolic
y.java:126)
at
org.openejb.transaction.TransactionContextInterceptor.invoke
(Transaction
ContextInterceptor.java:80)
at
org.openejb.slsb.StatelessInstanceInterceptor.invoke
(StatelessInstanceIn
terceptor.java:98)
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke
(ContainerPolic
y.java:140)
at
org.openejb.transaction.TransactionContextInterceptor.invoke
(Transaction
ContextInterceptor.java:80)
at
org.openejb.SystemExceptionInterceptor.invoke
(SystemExceptionInterceptor
.java:82)
at
org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at
org.openejb.proxy.EJBMethodInterceptor.intercept
(EJBMethodInterceptor.ja
va:129)
at
org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$
$4084bef.checkCustom
erCredit()
at
org.spec.jappserver.servlet.helper.SpecAction.atomicityTestTwo
(SpecActio
n.java:166)
at
org.spec.jappserver.servlet.helper.SpecServletAction.doAtomicityTests(
Sp
ecServletAction.java:1304)
at
org.spec.jappserver.servlet.SpecAppServlet.performTask
(SpecAppServlet.ja
va:166)
at
org.spec.jappserver.servlet.SpecAppServlet.doGet
(SpecAppServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.apache.geronimo.jetty.JettyServletHolder.handle
(JettyServletHolder.j
ava:99)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter
(Web
ApplicationHandler.java:830)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter
(Web
ApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch
(WebApplicationH
andler.java:471)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle
(WebApplicationCon
text.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:244
)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Note that the SQL prepared statement causing the error is correct and
references the table and fields that really exist in the database.
Executing this statement from a separate Java application using JDBC
causes no problem.
The code throwing this exception is:
org.openejb.tr
[jira] Commented: (GERONIMO-1410) Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - Hibernate based Web-app do not work
[ http://issues.apache.org/jira/browse/GERONIMO-1410?page=comments#action_12373752 ] John Sisson commented on GERONIMO-1410: --- This type of issue (where server implementation classes are causing problems) has been raised by a number of users. Even if a user uses the element, their configuration may not work in a later release of geronimo because we may have introduced some other libraries into the server that conflict with libraries in their App. Also we shouldn't be letting apps rely upon the open source libraries used in geronimo. Applications should be forced to include or reference the appropriate libraries, so changes in Geronimo don't affect them. Aaron had some thoughts on this in the following mail thread: http://www.mail-archive.com/user%40geronimo.apache.org/msg02533.html > Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - > Hibernate based Web-app do not work > > > Key: GERONIMO-1410 > URL: http://issues.apache.org/jira/browse/GERONIMO-1410 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: Clustering > Versions: 1.0 > Reporter: Gianny Damour > Priority: Critical > Fix For: 1.1 > > Spring Framework is defined by the "base" configuration > geronimo/jetty/1.0-SNAPSHOT/car. > This is an issue as Web-app leveraging the Hibernate integration provide by > Spring cannot be deployed. Basically, Hibernate classes cannot be loaded from > the configuration CL of geronimo/jetty/1.0-SNAPSHOT/car. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1820) corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint()
[ http://issues.apache.org/jira/browse/GERONIMO-1820?page=all ]
John Sisson closed GERONIMO-1820:
-
Fix Version: 1.0
(was: 1.2)
Resolution: Fixed
Fixed in rev 344299.
> corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint()
> -
>
> Key: GERONIMO-1820
> URL: http://issues.apache.org/jira/browse/GERONIMO-1820
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: startup/shutdown
> Versions: 1.0-M5
> Reporter: John Sisson
> Priority: Trivial
> Fix For: 1.0
>
> Noticed this email to the dev list (for M5) that didn't get a response. Need
> to determine if this bug still exists.
> Hello, all.
> Recently, I accidentally corrupted the config.ser file in
> bin/server.jar. It was my fault in this case, but this can also happen
> in the presence of ill-formed scripts that manipulate files in
> bin/server.jar or as a result of some bug in building procedures.
> Geronimo error handling/diagnostics in that situation were not intuitive
> to help me resolve the problem. I believe that an intuitive error
> message is possible to help other users that might experience corrupted
> config.ser files or other problem at the initial startup phase.
> Here's how it looks:
> C:\Geronimo> java -jar bin\server.jar
> Booting Geronimo Kernel (in Java 1.4.2_04)...
> java.lang.NullPointerException
> at
> org.apache.geronimo.system.main.ProgressBarStartupMonitor.repaint()V(Pro
> gressBarStartupMonitor.java:362)
> at
> org.apache.geronimo.system.main.ProgressBarStartupMonitor.serverStartFai
> led(Ljava.lang.Exception;)V(ProgressBarStartupMonitor.java:344)
> at
> org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:277)
> at
> org.apache.geronimo.system.main.Daemon.([Ljava.lang.String;)V(Daem
> on.java:78)
> at
> org.apache.geronimo.system.main.Daemon.main([Ljava.lang.String;)V(Daemon
> .java:316)
> To reproduce it, you can just write some trash to
> bin/server.jar/META-INF/config.ser and try to run Geronimo as shown
> above.
> Note that there's completely no information in the stack about why the
> crash really occured. I investigated, and here's what I found.
> Looks like the bug is in
> org.apache.geronimo.system.main.Daemon.doStartup() method. I here
> describe the bug basing on 1.0 M5 version (including source code) I've
> downloaded, using the line numbers to reference the code parts.
> The doStartup() method is a big try-catch block. The catch block looks
> like this:
> 275} catch (Exception e) {
> 276if(monitor != null) {
> 277monitor.serverStartFailed(e);
> 278}
> 279e.printStackTrace();
> 280System.exit(3);
> 281throw new AssertionError();
> 282}
> As you can see, monitor.serverStartFailed() method is called (277) if
> monitor is not null. And monitor is always non-null as it is initialized
> in initializeSystem() method (116, 118) that is called from constructor
> (73) before doStartup() method is called (78). In other words,
> monitor.serverStartFailed() method is always called.
> monitor object is really an instance of
> org.apache.geronimo.system.main.ProgressBarStartupMonitor class, and its
> serverStartFailed() method looks like this:
> 343currentOperation = "Startup failed";
> 344repaint();
> 345out.println();
> 346problem.printStackTrace(out);
> It calls repaint() method, which uses the configStatus field (362, 363)
> which is initialized by foundConfigurations() method (64).
> Now, we get back to Daemon.doStartup() method and see where
> monitor.foundConfigurations() method is called. It's line 219.
> It means that, if some exception occurs in lines 124 to 219 (in my
> example, it's line 149), the exception handler (277) would throw a
> NullPointerException (because monitor.configStatus field is not
> initialized) and woudn't have a chance to report the real problem (279).
> If we, for example, comment out line 277:
> 275} catch (Exception e) {
> 276if(monitor != null) {
> 277//monitor.serverStartFailed(e);
> 278}
> 279e.printStackTrace();
> 280System.exit(3);
> 281throw new AssertionError();
> 282}
> we immediately get the proper stack:
> C:\Geronimo> java -jar bin\server.jar
> Booting Geronimo Kernel (in Java 1.4.2_04)...
> java.io.StreamCorruptedException: invalid stream header
> at java.io.ObjectInputStream.readStreamHeader()V(Unknown Source)
> at
> java.io.ObjectInputStream.(Ljava.io.InputStream;)V(Unknown Source)
> at
> org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:147)
> at
> org.apache.geronimo.system.main.Daemon.([Ljava.lang.String;)V(Daem
> on.java:78)
>
Merging from 1.1 to HEAD
So I'm putting some stuff into 1.1, some of which is related to config IDs and some of which is not. My question is, for the stuff unrelated to config IDs, should I be merging to HEAD right away? Or is it going to be easier if I don't and we merge "everything" at once later? I have also previously put some things into HEAD which I would like to get into 1.1. I assume I should merge those to 1.1 soon, because I expect we will prepare the 1.1 release before attempting to fully merge 1.1 into HEAD. Is that right? Thanks, Aaron
[jira] Created: (GERONIMO-1821) "maven new4" in 1.1 leaves loads of /tmp/packageNNNNN.tmpdir directories behind
"maven new4" in 1.1 leaves loads of /tmp/packageN.tmpdir directories behind --- Key: GERONIMO-1821 URL: http://issues.apache.org/jira/browse/GERONIMO-1821 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem, Maven Plugins for G Versions: 1.1 Environment: Linux Reporter: Aaron Mulder Fix For: 1.1 After a few days of development, these (and other Geronimo temp) directories were consuming 2.4 GB. This is with the server shut down, so it's not like they were just going to be deleted later. We should clean up after ourselves better. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Long Path Proposal
Sorry hit the send button to quick... The biggest ding against the equinox code is the license. The code is not apache licensed so I can't for it to Geronimo and I'm not an equinox committer so I can't get changes in. Even if I did get the changes in, I'd have to wait for a release anytime we wanted a change to the class loader. Considering how critical the CL is to Geronimo, I think we should have the code in our tree. -dain On Apr 8, 2006, at 3:01 PM, Dain Sundstrom wrote: one-jar only supports one level of nesting I'm not a fan of the equinox code base. I normally spend forever searching for stuff and then the code is very weird since they seem to be supporting super old versions of java. Thanks for the links, but the emory code will be easy to work with. -dain On Apr 8, 2006, at 2:47 PM, Sachin Patel wrote: Dain, I'm not sure if this helps or not... http://one- jar.sourceforge.net/. Also I think equinox recently added support for packaged bundles containing nested jars. - sachin On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote: On Apr 7, 2006, at 7:21 PM, John Sisson wrote: Dain Sundstrom wrote: Unpacked archives in the repository: The solution is to not place unpacked archives in our repository. I (dain) am going to look at using a class loader that can read from classes and resources from jars nested in jars. Assuming we can find or write a class loader such a class loader, we will need to assure that Tomcat and Jetty can work from a packed archive. Also need to ensure/test that a security manager policy file can grant permissions for all JARS in a CAR or individual nested JARs using a codebase URL in the policy file so users have the same level of control they would have had in the config-store (at the same time solving the issue with the policy files needing to be changed due to the numbered directories in the config-store): http://mail-archives.apache.org/mod_mbox/geronimo-user/ 200602.mbox/[EMAIL PROTECTED] %3e I'm planing starting with the emory university resource class loader which supports all the security stuff like URLClassLoader, but is public domain and much more modular. Specifically, I think it will be easy to implement nested jar support via unpacking to a temp directory. -dain
Re: Long Path Proposal
one-jar only supports one level of nesting I'm not a fan of the equinox code base. I normally spend forever searching for stuff and then the code is very weird since they seem to be supporting super old versions of java. Thanks for the links, but the emory code will be easy to work with. -dain On Apr 8, 2006, at 2:47 PM, Sachin Patel wrote: Dain, I'm not sure if this helps or not... http://one- jar.sourceforge.net/. Also I think equinox recently added support for packaged bundles containing nested jars. - sachin On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote: On Apr 7, 2006, at 7:21 PM, John Sisson wrote: Dain Sundstrom wrote: Unpacked archives in the repository: The solution is to not place unpacked archives in our repository. I (dain) am going to look at using a class loader that can read from classes and resources from jars nested in jars. Assuming we can find or write a class loader such a class loader, we will need to assure that Tomcat and Jetty can work from a packed archive. Also need to ensure/test that a security manager policy file can grant permissions for all JARS in a CAR or individual nested JARs using a codebase URL in the policy file so users have the same level of control they would have had in the config-store (at the same time solving the issue with the policy files needing to be changed due to the numbered directories in the config-store): http://mail-archives.apache.org/mod_mbox/geronimo-user/ 200602.mbox/[EMAIL PROTECTED] I'm planing starting with the emory university resource class loader which supports all the security stuff like URLClassLoader, but is public domain and much more modular. Specifically, I think it will be easy to implement nested jar support via unpacking to a temp directory. -dain
Re: Long Path Proposal
Dain, I'm not sure if this helps or not... http://one- jar.sourceforge.net/. Also I think equinox recently added support for packaged bundles containing nested jars. - sachin On Apr 7, 2006, at 10:40 PM, Dain Sundstrom wrote: On Apr 7, 2006, at 7:21 PM, John Sisson wrote: Dain Sundstrom wrote: Unpacked archives in the repository: The solution is to not place unpacked archives in our repository. I (dain) am going to look at using a class loader that can read from classes and resources from jars nested in jars. Assuming we can find or write a class loader such a class loader, we will need to assure that Tomcat and Jetty can work from a packed archive. Also need to ensure/test that a security manager policy file can grant permissions for all JARS in a CAR or individual nested JARs using a codebase URL in the policy file so users have the same level of control they would have had in the config-store (at the same time solving the issue with the policy files needing to be changed due to the numbered directories in the config-store): http://mail-archives.apache.org/mod_mbox/geronimo-user/200602.mbox/ [EMAIL PROTECTED] I'm planing starting with the emory university resource class loader which supports all the security stuff like URLClassLoader, but is public domain and much more modular. Specifically, I think it will be easy to implement nested jar support via unpacking to a temp directory. -dain
TranQL issue at SPECjAppServer2004 atomicity tests
Hi, all,
I've successfuly deployed SPECjAppServer2004 benchmark on Geronimo 1.0
(see http://issues.apache.org/jira/browse/GERONIMO-1800), but I have
trouble running the basic atomicity tests
(http://localhost:8080/SPECjAppServer/ page, link "Atomicity Tests")
that check the correctness of the benchmark operation - all three tests
are marked FAILED.
The investigation (see below) showed that the root cause for the problem
is the following piece of code:
org.tranql.connector.jdbc.ManagedJDBCConnection:
123 public XAResource getXAResource() throws ResourceException {
124 throw new NotSupportedException("XAResource not available from
a LocalTransaction connection");
125 }
The question is, how critical this situation is? Does it mean
SPECjAppServer2004 uses things it shouldn't use? Or the problem lies in
TranQL implementation, or maybe Derby database or Derby JDBC driver? Or
does it mean SPECjAppServer2004 can't run on Geronimo at all?
Any ideas, suggestion and comments are highly welcome!
Thanks!
Here's the original stack displayed in Geronimo console window at each
atomicity tests' run:
javax.transaction.TransactionRolledbackException:
javax.ejb.FinderException: Error executing statement: SELECT C.C_ID FROM
C_CUSTOMER C WHERE C.C_ID = ?
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
y.java:126)
at
org.openejb.transaction.TransactionContextInterceptor.invoke(Transaction
ContextInterceptor.java:80)
at
org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceIn
terceptor.java:98)
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
y.java:140)
at
org.openejb.transaction.TransactionContextInterceptor.invoke(Transaction
ContextInterceptor.java:80)
at
org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor
.java:82)
at
org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at
org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.ja
va:129)
at
org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$4084bef.checkCustom
erCredit()
at
org.spec.jappserver.servlet.helper.SpecAction.atomicityTestTwo(SpecActio
n.java:166)
at
org.spec.jappserver.servlet.helper.SpecServletAction.doAtomicityTests(Sp
ecServletAction.java:1304)
at
org.spec.jappserver.servlet.SpecAppServlet.performTask(SpecAppServlet.ja
va:166)
at
org.spec.jappserver.servlet.SpecAppServlet.doGet(SpecAppServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.j
ava:99)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:830)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web
ApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
andler.java:471)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
text.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Note that the SQL prepared statement causing the error is correct and
references the table and fields that really exist in the database.
Executing this statement from a separate Java application using JDBC
causes no problem.
The code throwing this exception is:
org.openejb.transaction.ContainerPolicy$TxRequired.invoke():
117try {
118ejbInvocation.setTransactionContext(callerContext);
119return interceptor.invoke(ejbInvocation);
120} catch (Throwable t){
121callerContext.setRollbackOnly();
122if (ejbInvocation.getType().isLocal()) {
123 throw new
TransactionRolledbackLocalException().initCause(t);
124} else {
125// can't set an initCause on a
TransactionRolledbackException
126 -> throw new TransactionRolledbackException(t.getMessage());
127}
128} finally {
129ejbInvocation
[jira] Commented: (GERONIMO-1820) corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint()
[
http://issues.apache.org/jira/browse/GERONIMO-1820?page=comments#action_12373748
]
Vasily Zakharov commented on GERONIMO-1820:
---
Well, I couldn't reproduce the problem on Geronimo 1.0. Probably it got fixed.
> corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint()
> -
>
> Key: GERONIMO-1820
> URL: http://issues.apache.org/jira/browse/GERONIMO-1820
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: startup/shutdown
> Versions: 1.0-M5
> Reporter: John Sisson
> Priority: Trivial
> Fix For: 1.2
>
> Noticed this email to the dev list (for M5) that didn't get a response. Need
> to determine if this bug still exists.
> Hello, all.
> Recently, I accidentally corrupted the config.ser file in
> bin/server.jar. It was my fault in this case, but this can also happen
> in the presence of ill-formed scripts that manipulate files in
> bin/server.jar or as a result of some bug in building procedures.
> Geronimo error handling/diagnostics in that situation were not intuitive
> to help me resolve the problem. I believe that an intuitive error
> message is possible to help other users that might experience corrupted
> config.ser files or other problem at the initial startup phase.
> Here's how it looks:
> C:\Geronimo> java -jar bin\server.jar
> Booting Geronimo Kernel (in Java 1.4.2_04)...
> java.lang.NullPointerException
> at
> org.apache.geronimo.system.main.ProgressBarStartupMonitor.repaint()V(Pro
> gressBarStartupMonitor.java:362)
> at
> org.apache.geronimo.system.main.ProgressBarStartupMonitor.serverStartFai
> led(Ljava.lang.Exception;)V(ProgressBarStartupMonitor.java:344)
> at
> org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:277)
> at
> org.apache.geronimo.system.main.Daemon.([Ljava.lang.String;)V(Daem
> on.java:78)
> at
> org.apache.geronimo.system.main.Daemon.main([Ljava.lang.String;)V(Daemon
> .java:316)
> To reproduce it, you can just write some trash to
> bin/server.jar/META-INF/config.ser and try to run Geronimo as shown
> above.
> Note that there's completely no information in the stack about why the
> crash really occured. I investigated, and here's what I found.
> Looks like the bug is in
> org.apache.geronimo.system.main.Daemon.doStartup() method. I here
> describe the bug basing on 1.0 M5 version (including source code) I've
> downloaded, using the line numbers to reference the code parts.
> The doStartup() method is a big try-catch block. The catch block looks
> like this:
> 275} catch (Exception e) {
> 276if(monitor != null) {
> 277monitor.serverStartFailed(e);
> 278}
> 279e.printStackTrace();
> 280System.exit(3);
> 281throw new AssertionError();
> 282}
> As you can see, monitor.serverStartFailed() method is called (277) if
> monitor is not null. And monitor is always non-null as it is initialized
> in initializeSystem() method (116, 118) that is called from constructor
> (73) before doStartup() method is called (78). In other words,
> monitor.serverStartFailed() method is always called.
> monitor object is really an instance of
> org.apache.geronimo.system.main.ProgressBarStartupMonitor class, and its
> serverStartFailed() method looks like this:
> 343currentOperation = "Startup failed";
> 344repaint();
> 345out.println();
> 346problem.printStackTrace(out);
> It calls repaint() method, which uses the configStatus field (362, 363)
> which is initialized by foundConfigurations() method (64).
> Now, we get back to Daemon.doStartup() method and see where
> monitor.foundConfigurations() method is called. It's line 219.
> It means that, if some exception occurs in lines 124 to 219 (in my
> example, it's line 149), the exception handler (277) would throw a
> NullPointerException (because monitor.configStatus field is not
> initialized) and woudn't have a chance to report the real problem (279).
> If we, for example, comment out line 277:
> 275} catch (Exception e) {
> 276if(monitor != null) {
> 277//monitor.serverStartFailed(e);
> 278}
> 279e.printStackTrace();
> 280System.exit(3);
> 281throw new AssertionError();
> 282}
> we immediately get the proper stack:
> C:\Geronimo> java -jar bin\server.jar
> Booting Geronimo Kernel (in Java 1.4.2_04)...
> java.io.StreamCorruptedException: invalid stream header
> at java.io.ObjectInputStream.readStreamHeader()V(Unknown Source)
> at
> java.io.ObjectInputStream.(Ljava.io.InputStream;)V(Unknown Source)
> at
> org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:147)
> at
> org.apache.geronimo.system.main.Daemon.([Ljava.lang.String;)V(
Re: Geronimo peak performance
When preparing for the test, have a look at the very interesting cpustat/cputrack. Without this you won't really be able to judge on the cpu usage. Classical tools like sar/vmstat/prstat easily lead to wrong results (the amount of work a single strand [hardware thread] is able to do is not fixed. It really shares the core with the other strands. If they stall, it will execute on every cycle, if all 4 strands are busy each one will only execute on every 4th cycle. So the cpu power available to a strand is dynamic, but tools like prstat are not able to show that. For memory bus usage busstat is the way to go. If you need more info, you could start an off topic thread or mail me directly. Rainer Jeff Genender wrote: Yep...each core will handle 4 hardware threads. It was built for multiple threads and a JVM (multithreaded of course) is made for this box. For an appserver under load, I think the numbers should be impressive on this box. The cool thing about this machine is, each core is viewed as 4 cpus. That means this box looks like it has 16 CPUs running (4 cores x 4 hardware threads)! I can't wait to pound on this and see what it can do. I am going to have T2000->T2000 trials going on to maximize the throughput for CPU. They come with 4 1 Ghz Ethernet ports each, so I am going to pipe these up and hopefully there will be zero bottleneck on IO.
Re: M2 migration status
I had the same build break when I was using an old version of /etc/project.properties or /pom.xml, which had the activemq_property set to 3.2. activeMQ 3.2 was moved out of the incubator in leiu of v. 4. But it looks like they've upgraded the /etc/project.properties and /pom.xml file in the repo to use 4.0-SNAPSHOT, so perhaps check those out or manually change the activemq_version, activeMqVersion property? - Original Message - From: "Prasad Kashyap" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 05, 2006 10:59 PM Subject: Re: M2 migration status Anita, I found and fixed that problem in this JIRA http://issues.apache.org/jira/browse/GERONIMO-1660. The patch is called applications-pom.patch. Jacek, please apply this and the other console patch too. Now there is this build break: [INFO] Failed to resolve artifact. required artifacts missing: incubator-activemq:activemq-ra:jar:3.2 incubator-activemq:activemq-core:jar:3.2 for the artifact: org.apache.geronimo.modules:geronimo-activemq-embedded-rar:rar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), maven2-central (http://repo1.maven.org/maven2), Apache CVS (http://cvs.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) Cheers Prasad On 4/5/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: org.apache.geronimo.cars sounds good to me. That would be the pom in geronimo/applications dir. I see the pom exists in the trunk (http://svn.apache.org/viewcvs.cgi/geronimo/trunk/applications/pom.xml?rev=390662&view=log) If you have a pom there, do a 'mvn -N' in that dir. You shouldn't have to. But that'll get u going for now. Let me do a new top down build. Cheers Prasad On 4/5/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > Hi All, > We need a gropuId for cars. One possibility is > org.apache.geronimo.cars. comments ? > Prasad or Jacek, I am at rev 391200. I am building with clean repo. > A pom seem to be missing. > > Thanks > Anita > > > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > GroupId: org.apache.geronimo.applications > ArtifactId: applications-parent > Version: 1.2-SNAPSHOT > > Reason: Unable to download the artifact from any repository > > org.apache.geronimo.applications:applications-parent:pom:1.2-SNAPSHOT > > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > > > --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > > Comments inline - > > > > On 3/30/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > > > On 3/27/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > > > Having hit a roadblock with the assembly-plugin (details here- > > > > http://issues.apache.org/jira/browse/GERONIMO-1737), I've moved > > on to > > > > migrating the applications now. > > > > > > Hi Prasad, > > > > Hi Jacek, > > > > > > > > I think I found a solution to this. What about keeping the list in > > > pom.xml as 's? It could process the list and do what the > > > current plugin does. I'll have to give it a shot. If it doesn't > > work > > > I'll commit the already-generated-by-M1-plugin files to the repo to > > > let us move on. > > > > > > Keeping the list in the won't help. There is a lot more > > information that needs to be passed to the plugin than just the name. > > At the very least, there's the destination directory. Then there's > > some special post-processing like copying schema files into a > > flattened structure. > > > > We cannot use the M1 generated plugin because it depends on tags in > > the project.xml to work on. We won't have any such in our pom.xml. > > We'll have to revisit this big time in a separate thread when the > > config changes have stabilized. > > > > > > > > Once Anita is done with the packaging plugin, we begin migrating > > configs. > > > > > > +1 > > > > Anita, how far along are you on the packaging plugin ? > > > > > -- > > > Jacek Laskowski > > > > Cheers > > Prasad > > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
Re: Cannot build 1.1 on Windows - long file paths
Please, stay away from config/repos in DB :D I've seen that before and I really hated it. I can come up with a lond detailed list why we should not go that way ;) Cheers! Hernan Jason Dillon wrote: Good time for everyone to go buy a Mac :-) Is there any version of any windows fs that is not crippled with this limitation? Its a real pity that we have to work around muck like this... :-( * * * What if the repo was not backed by a filesystem... but maybe a fast database or something similar? Then paths could be as long as we want, but the physical representation could be tailored for lame operating systems. This would mean we need more tools to get at the data and to put in the data... but I think that would be generally a good thing anyways. --jason On Apr 7, 2006, at 12:25 PM, Matt Hogstrom wrote: I'm not blaming the m2 structure. One has to acknowledge that it accounts for more than 15% of the length (per your comment below). 15% is not insignificant but I'll concede that this is nowhere near the whole problem. It is compunding of the length due to nesting modules. Daytrader is a fair example of this. This example is from a build from this morning in branches/1.1. I omitted the / Users/hogstrom/dev/geronimo/branches/1.1/assemblies/j2ee-tomcat/ target/ prefix. geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-tomcat/ 1.1-SNAPSHOT/daytrader-derby-tomcat-1.1-SNAPSHOT.car/daytrader- web-1.1-SNAPSHOT.war/ Repeated items like derby-tomcat-1.1-SNAPSHOT doesn't help :) BTW, Geronimo is not the only one to suffer from this issue. The restriction is a problem on Windows I think we've been flirting with it for sometime. It has now just bit us hard. Dain Sundstrom wrote: Please stop blaming the m2 repo structure for this problem. The m2 repo structure only increased the path of our longest path by 36 characters. The true problem is that David and I moved the unpacked configurations into the repository. We did this because of the chunkiness of the numbered directories in the config- store directory. The m2 repository structure makes querying the repository for version numbers possible and it is this querying that makes optional version numbers possible. I think we have two issues that both must be addressed: 1) The ears we generate in our build have very long internal paths, 154 characters. This is just bad form, and vastly reduces the user path head room. > 2) We need to move the unpacked ears our of the repository and into a separate flat directory structure. I can look at the second one later today after fixing the redeploy command. Can someone take a look at getting our build to jar up the classes and compiled jsps in our build. I'll fix the generated classes in our build. -dain On Apr 7, 2006, at 6:50 AM, Matt Hogstrom wrote: Thinking about this some more I believe we need to make a good decision here as having to revisit this issue in the future will cause users to have to change how the server works. I've been talking to a new user that has a larger server farm and is very interested in the Geronimo server as their new foundation. However, they run a few thousand servers and are VERY sensitive to changes in the behaviour of the server in terms of how it impacts them. Changes to the repsoistory will affect their operational experience dramatically and they do run Windows (go Bill Gates). They are watching this thread with keen interest. Their biggest concern is changing how their build and distribution system works and changes in this area is highly disruptive for them. My view of the problem is that there are really three distinct areas of a path. They are the user area, the server area and the application area. Let me splain... | | 1 | 222 ... C:\my\directory\before\geronimo\geronimo-1.1\repository \com.apache.geronimo\console-1.1\appArtifacts The area in the 0's are controlled by the user and we need to leave more headroom than a few characters so they can manage multiple deployments of Geronimo; this could include multiple versions or multiple deployments. The users probably enjoy flexibility in naming as much as we do. We don't have control over this but we influence how much headroom is available. The 1's is really the area we have control over as this is the server proper. This includes the area from the top of the tree to the end of where the files we create end. So, for instance, this includes var, repository, etc. Since were currently experiencing this problem in the respository I think we should focus on this area. Finally, the 2's are the area that include the application and Maven dependent information. The Maven naming convention is verbose. The current implementation needs to be changed, the
Re: Cannot build 1.1 on Windows - long file paths
Hi All, here are some thoughts from my old IT Spec perspective :) Maybe I'm smoking something but wouldn't it be easier for the end user if we just offer them a simpler directory structure for the applications !?!?!? - This structure would be beneficial from a production stand point / here we put all the product applications. Very little end user updates here, maybe some customization at the initial build time if they are customizing Geronimo. We could keep all the apps JARed in this structure. / here we put all the user applications deployed via the deployer tool or the console. Here is where we have the bigger problem if the users use the same philosophy as we do with maven. I think here is where we need to focus. / this is within the dir. It will not be used too often in production, eitherway, most of the apps deployed here will be packaged as a jar or ear so we should not see any problems with the naming here. - The same structure from a development/customization stand point / lots of updates from the end user. It might still be more convenient to maintain a short naming convention for easier browseability (hmmm, does that word actually exists!?). What is the problem using back the jars? repackaging? can we provide a tool (script, classloader!?) for updating the jar automatically? / not much end user interaction, most of the testing may be performed via hot deployment. / same as before, most of the apps deployed here will be packaged as a jar or ear so we should not see any problems with the naming here. Cheers! Hernan David Jencks wrote: I've thought about not unpacking car files but rather flattening everything in them and writing a classloader that can deal with offsets within a jar file. This would completely solve the problem except for peoples desire to fiddle with jsp files on the fly. For this, maybe we should allow a car file has the config.ser (in xml :-) as now but the rest of it is a map to the actual locations of the files? I think it might be possible to include this in either a second "development-friendly" config store (in a special location) or the standard config store. thanks david jencks On Apr 7, 2006, at 10:29 AM, Dain Sundstrom wrote: Please stop blaming the m2 repo structure for this problem. The m2 repo structure only increased the path of our longest path by 36 characters. The true problem is that David and I moved the unpacked configurations into the repository. We did this because of the chunkiness of the numbered directories in the config-store directory. The m2 repository structure makes querying the repository for version numbers possible and it is this querying that makes optional version numbers possible. I think we have two issues that both must be addressed: 1) The ears we generate in our build have very long internal paths, 154 characters. This is just bad form, and vastly reduces the user path head room. 2) We need to move the unpacked ears our of the repository and into a separate flat directory structure. I can look at the second one later today after fixing the redeploy command. Can someone take a look at getting our build to jar up the classes and compiled jsps in our build. I'll fix the generated classes in our build. -dain On Apr 7, 2006, at 6:50 AM, Matt Hogstrom wrote: Thinking about this some more I believe we need to make a good decision here as having to revisit this issue in the future will cause users to have to change how the server works. I've been talking to a new user that has a larger server farm and is very interested in the Geronimo server as their new foundation. However, they run a few thousand servers and are VERY sensitive to changes in the behaviour of the server in terms of how it impacts them. Changes to the repsoistory will affect their operational experience dramatically and they do run Windows (go Bill Gates). They are watching this thread with keen interest. Their biggest concern is changing how their build and distribution system works and changes in this area is highly disruptive for them. My view of the problem is that there are really three distinct areas of a path. They are the user area, the server area and the application area. Let me splain... | | 1 | 222 ... C:\my\directory\before\geronimo\geronimo-1.1\repository \com.apache.geronimo\console-1.1\appArtifacts The area in the 0's are controlled by the user and we need to leave more headroom than a few characters so they can manage multiple deployments of Geronimo; this could include multiple versions or multiple deployments. The users probably enjoy flexibility in naming as much as we do. We don't have control over this but we influence how much headroom is available. The 1's is really the area we have control over as this is the server pro
Re: Embedded LDAP Server Viewer Portlet
On 4/8/06, Chris Cardona <[EMAIL PROTECTED]> wrote: > Hello All (Aaron, Joe, Paul), Hi Chris (although I'm not on the list ;)) > I would like to work on a new portlet for the console Is there an JIRA issue raised for it? If so, sign up for it and go ahead. Otherwise, please rise it and follow the aforementioned steps. I'm doing lots of portlet programming lately and can't wait till m2 conversion is done so I could jump in (and perhaps be included in the list of yours ;)). > Chris Jacek -- Jacek Laskowski http://www.laskowski.org.pl
