You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/04/05 02:01:39 UTC
[vote] Release Geronimo 1.2
The 1.2 release cut and awaiting your vote! All the files are
available in a staging area in my home dir on people.
http://people.apache.org/~dain/dist
geronimo-1.2-src
geronimo-framework-1.2
geronimo-jetty-minimal-1.2
geronimo-tomcat-minimal-1.2
geronimo-jetty-j2ee-1.2
geronimo-tomcat-j2ee-1.2
Additionally the maven repository with all of the modules, configs,
assemblies, etc. is here:
http://people.apache.org/~dain/stage/org/apache/geronimo
All archives contain LICENSE and NOTICE. Each binary jar is also
accompanied by source, javadoc, pom and all are signed, md5-ed, and
secure-hashed. Keys file available here:
http://people.apache.org/dist/geronimo/KEYS
Svn tag is here:
http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
Here's my +1!
-dain
Re: [vote] Release Geronimo 1.2
Posted by Paul McMahan <pa...@gmail.com>.
+1
I will update the 1.2 plugin catalog when the artifacts have been
published to central. For now I'm testing the plugin repo and
installation process by hacking my /etc/hosts and serving up
everything locally.
Thanks for the excellent RM work Dain and Alan.
Best wishes,
Paul
On Apr 4, 2007, at 8:01 PM, Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are
> available in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
Re: [vote] Release Geronimo 1.2
Posted by Rick McGuire <ri...@gmail.com>.
+1
Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are
> available in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>
Re: [vote] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
+1
As far as the three issues brought up:
Slow startup - Doesn't bother me much
NPE on shutdown - There is a patch now for the NPE
(https://issues.apache.org/jira/browse/GERONIMO-3068)
Derby connection problems - Couldn't duplicate
Jay
Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are
> available in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>
>
>
Re: [vote] Release Geronimo 1.2
Posted by Jason Dillon <ja...@planet57.com>.
IMO we moved from 1.2 to 2.0 *way* to quickly, leaving 1.2 out in the
cold... I was afraid this was going to happen. But we can't really
just drop it.
I believe we need to release 1.2, even if it has some minor issues.
I'm holding off my vote at the moment until I can finish my
validation... but chances are its going to be plus-one.
--jason
On Apr 5, 2007, at 11:00 AM, Aaron Mulder wrote:
> 0: Given the attention on 2.0, I'm not optimistic about there being
> another release in the 1.2.x stream, and I don't really like the
> problems Hernan found (database pools and shutdown exception). I'll
> change to a +1 if someone commits to fixing and releasing these in a
> 1.2.1 fairly quickly.
>
> Thanks,
> Aaron
>
> On 4/4/07, Dain Sundstrom <da...@iq80.com> wrote:
>> The 1.2 release cut and awaiting your vote! All the files are
>> available in a staging area in my home dir on people.
>>
>> http://people.apache.org/~dain/dist
>> geronimo-1.2-src
>> geronimo-framework-1.2
>> geronimo-jetty-minimal-1.2
>> geronimo-tomcat-minimal-1.2
>> geronimo-jetty-j2ee-1.2
>> geronimo-tomcat-j2ee-1.2
>>
>> Additionally the maven repository with all of the modules, configs,
>> assemblies, etc. is here:
>>
>> http://people.apache.org/~dain/stage/org/apache/geronimo
>>
>> All archives contain LICENSE and NOTICE. Each binary jar is also
>> accompanied by source, javadoc, pom and all are signed, md5-ed, and
>> secure-hashed. Keys file available here:
>>
>> http://people.apache.org/dist/geronimo/KEYS
>>
>> Svn tag is here:
>>
>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>>
>> Here's my +1!
>>
>> -dain
>>
>>
>>
>>
>>
Re: [vote] Release Geronimo 1.2
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
0: Given the attention on 2.0, I'm not optimistic about there being
another release in the 1.2.x stream, and I don't really like the
problems Hernan found (database pools and shutdown exception). I'll
change to a +1 if someone commits to fixing and releasing these in a
1.2.1 fairly quickly.
Thanks,
Aaron
On 4/4/07, Dain Sundstrom <da...@iq80.com> wrote:
> The 1.2 release cut and awaiting your vote! All the files are
> available in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>
>
Re: [vote] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
+1
I downloaded the Tomcat distribution and looked at the legal and
license files.
Also verified a few of the .asc gpg signatures against the binaries
and those look good as well.
Deployed and tested DayTrader 1.2 in Direct, EJB and Session modes as
well as tested the WebServices elements.
All Transactions executed as expected and there were no exceptions
thrown. Deployment was smooth and it was a "clean" experience.
Looks good...thanks for hunking on this.
On Apr 4, 2007, at 8:01 PM, Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are
> available in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Wait (crap)
This change builds, but fails the openejb tests
(forgot to run those before sending out the patch for confirmation)
Jay D. McHugh wrote:
> Hello all,
>
> New attempt that doesn't just hide the problem.
>
> I managed to find reference on how to make a linked list behave as
> synchronized (above and beyond simply trying to access them from
> within synchronized code blocks).
>
> Attached is the patch - It is actually for OpenEJB...I'm going to wait
> until someone has a chance to confirm that it actually resolves the
> Geronimo/Daytrader issue then make the JIRA over on OpenEJB.
>
> Jay
>
> David Jencks wrote:
>> I don't think this is acceptable. There should be only one thread
>> working with the context at a time. Either this exception is caused
>> by modifying the collection in the same thread in which case we can
>> fix it easily or it is caused by more than one thread having access
>> to a context at once. Since by my reading of the code this is a
>> context attached to a stateless session bean instance, that would
>> mean that more than one thread is using a stateless session bean
>> instance at once, which is definitely cause to -1 the release.
>>
>> I hope there's another possibility I haven't thought of..... but
>> hiding the problem is not acceptable unless we really understand what
>> is going on and are really convinced it's harmless.
>>
>> thanks
>> david jencks
>>
>> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>>
>>> Chris (do you go by Chris or Christopher?),
>>>
>>> Here is a patch that I just wrote that allows the exit routine of
>>> ConnectionTrackingCoordinator to finish cleanly after a number (5)
>>> of attempts at removing the resource.
>>>
>>> If it fails after five tries, then the routine exits and throws a
>>> ResourceException (that will hopefully be caught further up the stack).
>>>
>>> Would you like to try it to see if it solves your concurrency problem?
>>>
>>> Jay
>>>
>>> Christopher Blythe wrote:
>>>> Doubtful... everything tested fine under light browser based
>>>> testing. As the exception suggests, this is a concurrency problem
>>>> that you would only hit under load.
>>>>
>>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>>
>>>> If Matt had no problem deploying and testing DT, could it be a
>>>> Java
>>>> version or classpath issue?
>>>>
>>>> That could explain the difference in the exception during
>>>> deployment
>>>> (and the problems during deployment could possibly explain the run
>>>> time
>>>> problems).
>>>>
>>>> Jay
>>>>
>>>> Christopher Blythe wrote:
>>>> > I use a commercial load driving tool... FYI, I'm fairly
>>>> certain that
>>>> > G-2.0 has the same issue.
>>>> >
>>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>>> <ma...@yahoo.com>
>>>> > <mailto:david_jencks@yahoo.com <ma...@yahoo.com>>>
>>>> wrote:
>>>> >
>>>> > I think we need to figure out why the
>>>> > concurrentModificationException is happening before we
>>>> release. I
>>>> > think that one possible reason is that we are multithreading
>>>> > stateless session bean instances. I hope this isn't the
>>>> cause....
>>>> > but IMO we need to find out.
>>>> >
>>>> > Chris, how do you run the several clients? manually or with
>>>> a tool?
>>>> >
>>>> > thanks
>>>> > david jencks
>>>> >
>>>> >
>>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>>> >
>>>> >> Gave it a shot... no luck. As soon as I started 2
>>>> clients, the
>>>> >> same exceptions started to pile up. I have attached the
>>>> >> geronimo.log. Also, noticed the following exception during
>>>> startup.
>>>> >>
>>>> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
>>>> >> connection from /127.0.0.1:28428: java.io.IOException: Wire
>>>> >> format negociation timeout: peer did not send his wire
>>>> format.
>>>> >> java.io.IOException: Wire format negociation timeout:
>>>> peer did
>>>> >> not send his wire format.
>>>> >> at
>>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>>> >> (WireFormatNegotiator.java :88)
>>>> >> at
>>>> >>
>>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
>>>>
>>>> >> at
>>>> org.apache.activemq.broker.TransportConnection.dispatch
>>>> >> (TransportConnection.java :1138)
>>>> >> at
>>>> >>
>>>> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
>>>>
>>>> >> at
>>>> >> org.apache.activemq.broker.TransportConnection.start
>>>> (TransportConnection.java
>>>> >> :885)
>>>> >> at
>>>> org.apache.activemq.broker.TransportConnector$1.onAccept
>>>> >> (TransportConnector.java:148)
>>>> >> at
>>>> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>>> (TcpTransportServer.java:167)
>>>> >> at java.lang.Thread.run (Thread.java:797)
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>>> <ma...@hogstrom.org>
>>>> >> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>>
>>>> wrote:
>>>> >>
>>>> >> Only a very light load from a few browsers. One thing
>>>> to try
>>>> >> is to increase the number of SLSBs in the pool.
>>>> >>
>>>> >> Can you add
>>>> >>
>>>> >> <session>
>>>> >> <ejb-name>TradeJDBC</ejb-name>
>>>> >>
>>>> <jndi-name>ejb/TradeJDBC</jndi-name>
>>>> >> <cache-size>100</cache-size>
>>>> >> </session>
>>>> >>
>>>> >> to your plan and redeploy. I added some support for
>>>> multiple
>>>> >> SLSBs in a pool for 1.2 which we did not have
>>>> before. This
>>>> >> will hopefully make it better and not worse :)
>>>> >>
>>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>>>> >>
>>>> >>> Matt...
>>>> >>>
>>>> >>> You mentioned that you deployed DayTrader 1.2...
>>>> did you
>>>> >>> happen to run it under load? JDBC/Direct mode looks
>>>> good;
>>>> >>> however, I am still seeing
>>>> ConcurrentModificationExceptions
>>>> >>> while attempting to run more than 1 client in Session
>>>> Direct
>>>> >>> mode (
>>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>>> >>> These exceptions are thrown throughout the duration
>>>> of the
>>>> >>> run. FYI - I deployed the same ear on Geronimo
>>>> 1.1.1 and
>>>> >>> didn't have a problem scaling up the users for Session
>>>> >>> Direct mode.
>>>> >>>
>>>> >>> java.util.ConcurrentModificationException
>>>> >>> at
>>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
>>>>
>>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>>>>
>>>>
>>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>>> >>> (FastMethod.java :53)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>> (FastMethodInvoker.java:38)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>>>>
>>>> >>> at
>>>> >>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>> >>> (GBeanInstance.java:820)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>> >>> ( ProxyMethodInterceptor.java:96)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>>> >>> at
>>>> >>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>>> (SystemExceptionInterceptor.java:35)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java
>>>>
>>>> >>> :49)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java:178)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
>>>>
>>>> (<generated>)
>>>> >>>
>>>> >>> at
>>>> >>>
>>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>> (FastMethodInvoker.java:38)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>> >>> (GBeanOperation.java:122)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
>>>> :57)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>> >>> (RawOperationInvoker.java:35)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
>>>>
>>>>
>>>> >>> (<generated>)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
>>>>
>>>> >>> (<generated>)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java:449)
>>>>
>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>> >>> web.TradeServletAction.doLogin
>>>> >>>
>>>> <http://web.TradeServletAction.doLogin>(TradeServletAction.java:364)
>>>> >>> at org.apache.geronimo.samples.daytrader .
>>>> >>> web.TradeAppServlet.performTask
>>>> >>>
>>>> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java:126)
>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>> >>> web.TradeAppServlet.doPost
>>>> >>>
>>>> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java :91)
>>>> >>> at javax.servlet.http.HttpServlet.service
>>>> >>> (HttpServlet.java:617)
>>>> >>> at
>>>> >>>
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java :690)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>> >>> (ApplicationFilterChain.java:252)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>> >>> (ApplicationFilterChain.java:173)
>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>> >>> web.OrdersAlertFilter.doFilter
>>>> >>>
>>>> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java:91)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>> (ApplicationFilterChain.java
>>>> >>> :202)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>> >>> (ApplicationFilterChain.java :173)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>>
>>>> >>> at
>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>> >>> (StandardContextValve.java:178)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java
>>>>
>>>> >>> :328)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>>> (GeronimoBeforeAfterValve.java:47)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>>>>
>>>> >>> at
>>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>>> >>> (ErrorReportValve.java:105)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
>>>>
>>>> >>> at
>>>> org.apache.catalina.connector.CoyoteAdapter.service
>>>> >>> (CoyoteAdapter.java :148)
>>>> >>> at
>>>> >>>
>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
>>>>
>>>> (Http11BaseProtocol.java
>>>> >>> :667)
>>>> >>> at
>>>> >>>
>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>
>>>> >>> at
>>>> >>>
>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
>>>> >>> (ThreadPool.java:684)
>>>> >>> at java.lang.Thread.run(Thread.java:797)
>>>> >>>
>>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>>> <ma...@planet57.com>
>>>> >>> <mailto:jason@planet57.com
>>>> <ma...@planet57.com>>> wrote:
>>>> >>>
>>>> >>> Aight, no worries. I still don't fully understand
>>>> all
>>>> >>> that plugin stuff... yet ;-)
>>>> >>>
>>>> >>> --jason
>>>> >>>
>>>> >>>
>>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>>> >>>
>>>> >>>> The change I have cued up replaces "
>>>> 1.2-SNAPSHOT" with
>>>> >>>> " 1.2" for all the catalog entries. So it would
>>>> break
>>>> >>>> anyone using the Geronimo plugin repo from a
>>>> >>>> 1.2-SNAPSHOT server (maybe not a huge deal).
>>>> Also,
>>>> >>>> I've tested the catalog updates by looping http
>>>> >>>> requests to repo1.maven.org/maven2
>>>> <http://repo1.maven.org/maven2>
>>>> >>>> <http://repo1.maven.org/maven2> back to my local
>>>> maven
>>>> >>>> repo. So I've made some assumptions about the
>>>> repo
>>>> >>>> layout that should probably be verified.
>>>> >>>>
>>>> >>>> Best wishes,
>>>> >>>> Paul
>>>> >>>>
>>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>>> >>>>
>>>> >>>>> Will it hurt anything to commit it now? Or
>>>> will it
>>>> >>>>> break things?
>>>> >>>>>
>>>> >>>>> --jason
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>>> >>>>>
>>>> >>>>>>
>>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>> >>>>>>
>>>> >>>>>>> I couldn't do much with the framework assembly
>>>> as it
>>>> >>>>>>> requires a plugin repository with 1.2
>>>> plugins and
>>>> >>>>>>> AFAIK there is no such plugin repository
>>>> available
>>>> >>>>>>> yet. Will you be making the plugins
>>>> available for
>>>> >>>>>>> 1.2 as you make the release available? If
>>>> not, then
>>>> >>>>>>> perhaps we shouldn't include the framework
>>>> assembly
>>>> >>>>>>> in the distribution.
>>>> >>>>>>
>>>> >>>>>> I updated the plugin catalog stuff in
>>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally
>>>> and ran
>>>> >>>>>> some quick tests of plugin download &
>>>> install from
>>>> >>>>>> maven repo. I'm ready to commit if/when the
>>>> 1.2
>>>> >>>>>> artifacts are published to central.
>>>> >>>>>>
>>>> >>>>>> Best wishes,
>>>> >>>>>> Paul
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> "I say never be complete, I say stop being perfect,
>>>> I say
>>>> >>> let... lets evolve, let the chips fall where they
>>>> may." -
>>>> >>> Tyler Durden
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> "I say never be complete, I say stop being perfect, I say
>>>> let...
>>>> >> lets evolve, let the chips fall where they may." - Tyler
>>>> Durden
>>>> >> <geronimo.log>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > "I say never be complete, I say stop being perfect, I say let...
>>>> lets
>>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>>
>>>>
>>>>
>>>>
>>>> --"I say never be complete, I say stop being perfect, I say let...
>>>> lets evolve, let the chips fall where they may." - Tyler Durden
>>> Index:
>>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>>
>>> ===================================================================
>>> ---
>>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>> (revision 526213)
>>> +++
>>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>> (working copy)
>>> @@ -124,7 +124,23 @@
>>>
>>> // if no connection remain clear context... we
>>> could support automatic commit, rollback or exception here
>>> if (connections.isEmpty()) {
>>> - i.remove();
>>> + boolean retry = false;
>>> + int numberOfRetries = 0;
>>> + do {
>>> + try {
>>> + i.remove();
>>> + } catch
>>> (java.util.ConcurrentModificationException ex) {
>>> + if (numberOfRetries < 5) {
>>> + retry = true;
>>> + } else {
>>> + retry = false;
>>> + }
>>> + numberOfRetries += 1;
>>> + }
>>> + } while (retry);
>>> + if (numberOfRetries >= 5) {
>>> + throw new
>>> ResourceException("ConcurrentModificationException - Unable to
>>> remove resource");
>>> + }
>>> }
>>> }
>>> } finally {
>>
>>
>>
>>
Re: [discuss] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
It sounds like this problem exists for 2.0 and 1.2. I'd like to get
DT running on 2.0 and debug the problem there which I am happy to do.
On Apr 9, 2007, at 10:33 AM, Jay D. McHugh wrote:
> I did some more thinking about this and I think that the CME is
> related to the connection problem.
>
> I think that a bean is failing to get a connection, so I tries to
> destroy itself and release its connections. Then (because of the
> initial connection problem) it hits an exception trying to release
> its resources, which causes it to try to destroy itself and release
> its resources...
>
> So, the iterator is already created further down the stack and
> trying to remove an element from it is not permitted - Causing the
> concurrent modification exception.
>
> If it were not for the exception being thrown, I think that it
> might have actually ended up causing an infinite loop.
>
> Could a flag be set in the context that indicates that the exit is
> in progress? Then the exit routine could first check for the flag
> and only be allowed to proceed if it is not already in progress
> somewhere else in the program stack.
>
> Or, if folk think this might be right (the recursive exiting), what
> about just catching the CME and letting the routine fail gracefully?
>
> Jay
>
> Matt Hogstrom wrote:
>>
>> On Apr 7, 2007, at 6:34 PM, Matt Hogstrom wrote:
>>
>>> I'll give it a spin tonight Jay...thanks
>> I did some work over the weekend with little success. I started
>> using Derby as the DB provider and ran into a set of issues around
>> connection management (no concurrent modification exceptions). In
>> JDBC mode things ran fine. In Session Direct Mode I experienced
>> the connection problem. Basically it was complaining about a
>> queue being full in the exception but I didn't get too involved in
>> diagnosing that.
>>
>> Chris, did you run this with Derby or another external DB?
>> Curious where the fault domain might be for this problem.
>>
>> I'll continue to work on this, but I want to stay on top of 2.0 as
>> there are lots of things to chase down wrt to dependencies so I
>> can't commit a lot of time to diagnosing this problem. Chris,
>> what's your ability to work on this?
>>
>>
>>
>>
>
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
I did some more thinking about this and I think that the CME is related
to the connection problem.
I think that a bean is failing to get a connection, so I tries to
destroy itself and release its connections. Then (because of the
initial connection problem) it hits an exception trying to release its
resources, which causes it to try to destroy itself and release its
resources...
So, the iterator is already created further down the stack and trying to
remove an element from it is not permitted - Causing the concurrent
modification exception.
If it were not for the exception being thrown, I think that it might
have actually ended up causing an infinite loop.
Could a flag be set in the context that indicates that the exit is in
progress? Then the exit routine could first check for the flag and only
be allowed to proceed if it is not already in progress somewhere else in
the program stack.
Or, if folk think this might be right (the recursive exiting), what
about just catching the CME and letting the routine fail gracefully?
Jay
Matt Hogstrom wrote:
>
> On Apr 7, 2007, at 6:34 PM, Matt Hogstrom wrote:
>
>> I'll give it a spin tonight Jay...thanks
> I did some work over the weekend with little success. I started using
> Derby as the DB provider and ran into a set of issues around
> connection management (no concurrent modification exceptions). In
> JDBC mode things ran fine. In Session Direct Mode I experienced the
> connection problem. Basically it was complaining about a queue being
> full in the exception but I didn't get too involved in diagnosing that.
>
> Chris, did you run this with Derby or another external DB? Curious
> where the fault domain might be for this problem.
>
> I'll continue to work on this, but I want to stay on top of 2.0 as
> there are lots of things to chase down wrt to dependencies so I can't
> commit a lot of time to diagnosing this problem. Chris, what's your
> ability to work on this?
>
>
>
>
Re: [discuss] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Apr 7, 2007, at 6:34 PM, Matt Hogstrom wrote:
> I'll give it a spin tonight Jay...thanks
I did some work over the weekend with little success. I started
using Derby as the DB provider and ran into a set of issues around
connection management (no concurrent modification exceptions). In
JDBC mode things ran fine. In Session Direct Mode I experienced the
connection problem. Basically it was complaining about a queue being
full in the exception but I didn't get too involved in diagnosing that.
Chris, did you run this with Derby or another external DB? Curious
where the fault domain might be for this problem.
I'll continue to work on this, but I want to stay on top of 2.0 as
there are lots of things to chase down wrt to dependencies so I can't
commit a lot of time to diagnosing this problem. Chris, what's your
ability to work on this?
Re: [discuss] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'll give it a spin tonight Jay...thanks
On Apr 7, 2007, at 5:27 PM, Jay D. McHugh wrote:
> I think I forgot to attach it (of course, the one that is probably
> right).
>
> Hopefully I'll remember now (but just in case here it is inline):
>
> Index: modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java
> ===================================================================
> --- modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (revision 526318)
> +++ modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (working copy)
> @@ -16,8 +16,8 @@
> */
> package org.apache.openejb.util;
>
> -import java.util.LinkedList;
> import java.io.Serializable;
> +import java.util.Stack;
>
> import org.apache.openejb.cache.InstanceFactory;
> import org.apache.openejb.cache.InstancePool;
> @@ -30,19 +30,19 @@
> public final class SoftLimitedInstancePool implements InstancePool,
> Serializable {
> private final InstanceFactory factory;
> private final int maxSize;
> - private transient final LinkedList pool;
> + private transient final Stack pool;
>
> public SoftLimitedInstancePool(final InstanceFactory factory,
> final int maxSize) {
> this.factory = factory;
> this.maxSize = maxSize;
> - pool = new LinkedList();
> + pool = new Stack();
> }
>
> public Object acquire() throws Exception {
> // get the instance from the pool if possible
> synchronized (this) {
> if (!pool.isEmpty()) {
> - return pool.removeFirst();
> + return pool.pop();
> }
> }
>
> @@ -55,7 +55,7 @@
> // if we are under the limit put it back in the pool at
> the head
> // this encourages reuse of the same instances to
> improve memory management
> if (pool.size() < maxSize) {
> - pool.addFirst(instance);
> + pool.push(instance);
> return true;
> }
> }
> @@ -84,7 +84,7 @@
> synchronized (this) {
> // add this new instance to the end
> // we prefer other users get older instances first
> - pool.addLast(instance);
> + pool.insertElementAt(instance, 0);
> }
> }
>
>
>
> Jay
>
> David Jencks wrote:
>> I think the mailing list removed your patch... anyway I don't see
>> it. Can you attach it to a jira or include it inline?
>>
>> thanks
>> david jencks
>>
>> On Apr 6, 2007, at 8:16 PM, Jay D. McHugh wrote:
>>
>>> Whew!
>>>
>>> Maybe now (I ran the openejb tests this time)
>>>
>>> From what I understand, java.util.Stack is internally sychronized
>>> since it is an extension of Vector which is synchronized.
>>>
>>> So, here is a patch that replaces the LinkedList with a Stack.
>>>
>>> It does pass the OpenEJB tests and will hopefully stand up under
>>> stress with daytrader under load.
>>>
>>> Sorry about the previous noise - I'm anxious to get G1.2 out so
>>> that everyone can get back to G2 - Plus, this same issue will
>>> need to be fixed in OpenEJB 3 if this corrects the problem.
>>>
>>> Anyway, hopefully this will get 1.2 closer to the door,
>>>
>>>
>>> Jay
>>>
>>> David Jencks wrote:
>>>> I don't think this is acceptable. There should be only one
>>>> thread working with the context at a time. Either this
>>>> exception is caused by modifying the collection in the same
>>>> thread in which case we can fix it easily or it is caused by
>>>> more than one thread having access to a context at once. Since
>>>> by my reading of the code this is a context attached to a
>>>> stateless session bean instance, that would mean that more than
>>>> one thread is using a stateless session bean instance at once,
>>>> which is definitely cause to -1 the release.
>>>>
>>>> I hope there's another possibility I haven't thought of..... but
>>>> hiding the problem is not acceptable unless we really understand
>>>> what is going on and are really convinced it's harmless.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>>>>
>>>>> Chris (do you go by Chris or Christopher?),
>>>>>
>>>>> Here is a patch that I just wrote that allows the exit routine
>>>>> of ConnectionTrackingCoordinator to finish cleanly after a
>>>>> number (5) of attempts at removing the resource.
>>>>>
>>>>> If it fails after five tries, then the routine exits and throws
>>>>> a ResourceException (that will hopefully be caught further up
>>>>> the stack).
>>>>>
>>>>> Would you like to try it to see if it solves your concurrency
>>>>> problem?
>>>>>
>>>>> Jay
>>>>>
>>>>> Christopher Blythe wrote:
>>>>>> Doubtful... everything tested fine under light browser based
>>>>>> testing. As the exception suggests, this is a concurrency
>>>>>> problem that you would only hit under load.
>>>>>>
>>>>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>>>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>>>>
>>>>>> If Matt had no problem deploying and testing DT, could it
>>>>>> be a Java
>>>>>> version or classpath issue?
>>>>>>
>>>>>> That could explain the difference in the exception during
>>>>>> deployment
>>>>>> (and the problems during deployment could possibly explain
>>>>>> the run
>>>>>> time
>>>>>> problems).
>>>>>>
>>>>>> Jay
>>>>>>
>>>>>> Christopher Blythe wrote:
>>>>>> > I use a commercial load driving tool... FYI, I'm fairly
>>>>>> certain that
>>>>>> > G-2.0 has the same issue.
>>>>>> >
>>>>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>
>>>>>> > <mailto:david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>>>
>>>>>> wrote:
>>>>>> >
>>>>>> > I think we need to figure out why the
>>>>>> > concurrentModificationException is happening before we
>>>>>> release. I
>>>>>> > think that one possible reason is that we are
>>>>>> multithreading
>>>>>> > stateless session bean instances. I hope this isn't
>>>>>> the
>>>>>> cause....
>>>>>> > but IMO we need to find out.
>>>>>> >
>>>>>> > Chris, how do you run the several clients? manually
>>>>>> or with
>>>>>> a tool?
>>>>>> >
>>>>>> > thanks
>>>>>> > david jencks
>>>>>> >
>>>>>> >
>>>>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>>>>> >
>>>>>> >> Gave it a shot... no luck. As soon as I started 2
>>>>>> clients, the
>>>>>> >> same exceptions started to pile up. I have attached
>>>>>> the
>>>>>> >> geronimo.log. Also, noticed the following exception
>>>>>> during
>>>>>> startup.
>>>>>> >>
>>>>>> >> 14:05:00,640 ERROR [TransportConnector] Could not
>>>>>> accept
>>>>>> >> connection from /127.0.0.1:28428:
>>>>>> java.io.IOException: Wire
>>>>>> >> format negociation timeout: peer did not send his
>>>>>> wire format.
>>>>>> >> java.io.IOException: Wire format negociation
>>>>>> timeout: peer did
>>>>>> >> not send his wire format.
>>>>>> >> at
>>>>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>>>>> >> (WireFormatNegotiator.java :88)
>>>>>> >> at
>>>>>> >>
>>>>>> org.apache.activemq.transport.MutexTransport.oneway
>>>>>> (MutexTransport.java:47)
>>>>>> >> at
>>>>>> org.apache.activemq.broker.TransportConnection.dispatch
>>>>>> >> (TransportConnection.java :1138)
>>>>>> >> at
>>>>>> >>
>>>>>> org.apache.activemq.broker.TransportConnection.processDispatch
>>>>>> (TransportConnection.java:805)
>>>>>> >> at
>>>>>> >> org.apache.activemq.broker.TransportConnection.start
>>>>>> (TransportConnection.java
>>>>>> >> :885)
>>>>>> >> at org.apache.activemq.broker.TransportConnector
>>>>>> $1.onAccept
>>>>>> >> (TransportConnector.java:148)
>>>>>> >> at
>>>>>> >>
>>>>>> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>>>>> (TcpTransportServer.java:167)
>>>>>> >> at java.lang.Thread.run (Thread.java:797)
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>>>>> <ma...@hogstrom.org>
>>>>>> >> <mailto:matt@hogstrom.org
>>>>>> <ma...@hogstrom.org>>> wrote:
>>>>>> >>
>>>>>> >> Only a very light load from a few browsers.
>>>>>> One thing
>>>>>> to try
>>>>>> >> is to increase the number of SLSBs in the pool.
>>>>>> >>
>>>>>> >> Can you add
>>>>>> >>
>>>>>> >> <session>
>>>>>> >> <ejb-name>TradeJDBC</ejb-name>
>>>>>> >> <jndi-name>ejb/TradeJDBC</
>>>>>> jndi-name>
>>>>>> >> <cache-size>100</cache-size>
>>>>>> >> </session>
>>>>>> >>
>>>>>> >> to your plan and redeploy. I added some
>>>>>> support for
>>>>>> multiple
>>>>>> >> SLSBs in a pool for 1.2 which we did not have
>>>>>> before. This
>>>>>> >> will hopefully make it better and not worse :)
>>>>>> >>
>>>>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe
>>>>>> wrote:
>>>>>> >>
>>>>>> >>> Matt...
>>>>>> >>>
>>>>>> >>> You mentioned that you deployed DayTrader
>>>>>> 1.2... did you
>>>>>> >>> happen to run it under load? JDBC/Direct mode
>>>>>> looks good;
>>>>>> >>> however, I am still seeing
>>>>>> ConcurrentModificationExceptions
>>>>>> >>> while attempting to run more than 1 client in
>>>>>> Session
>>>>>> Direct
>>>>>> >>> mode (
>>>>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>>>>> >>> These exceptions are thrown throughout the
>>>>>> duration of the
>>>>>> >>> run. FYI - I deployed the same ear on Geronimo
>>>>>> 1.1.1 and
>>>>>> >>> didn't have a problem scaling up the users for
>>>>>> Session
>>>>>> >>> Direct mode.
>>>>>> >>>
>>>>>> >>> java.util.ConcurrentModificationException
>>>>>> >>> at
>>>>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connect
>>>>>> ionTrackingCoordinator.exit
>>>>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connect
>>>>>> ionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
>>>>>> (<generated>)
>>>>>>
>>>>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>>>>> >>> (FastMethod.java :53)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>>>> (FastMethodInvoker.java:38)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>>>> (GBeanOperation.java:122)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>>>> >>> (GBeanInstance.java:820)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>>>>>> (RawInvoker.java:57)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>>>> (RawOperationInvoker.java:35)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>>>> >>> ( ProxyMethodInterceptor.java:96)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connect
>>>>>> ionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>>>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>>>>> (SystemExceptionInterceptor.java:35)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke
>>>>>> (DefaultSubjectInterceptor.java
>>>>>> >>> :49)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
>>>>>> (DefaultStatelessEjbContainer.java:178)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$
>>>>>> $FastClassByCGLIB$$7ad7a562.invoke
>>>>>> (<generated>)
>>>>>> >>>
>>>>>> >>> at
>>>>>> >>> net.sf.cglib.reflect.FastMethod.invoke
>>>>>> (FastMethod.java:53)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>>>> (FastMethodInvoker.java:38)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>>>> >>> (GBeanOperation.java:122)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>>>> (GBeanInstance.java:820)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>>>>>> (RawInvoker.java
>>>>>> :57)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>>>> >>> (RawOperationInvoker.java:35)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>>>> (ProxyMethodInterceptor.java:96)
>>>>>> >>> at
>>>>>> >>> org.apache.openejb.StatelessEjbContainer$
>>>>>> $EnhancerByCGLIB$$5c554f35.invoke
>>>>>>
>>>>>> >>> (<generated>)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.AbstractEjbDeployment.invoke
>>>>>> (AbstractEjbDeployment.java:195)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept
>>>>>> (EJBMethodInterceptor.java:145)
>>>>>> >>> at
>>>>>> >>> org.apache.openejb.proxy.SessionEJBObject$
>>>>>> $EnhancerByCGLIB$$f5a9c1b2.login
>>>>>> >>> (<generated>)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.samples.daytrader.TradeAction.login
>>>>>> (TradeAction.java:449)
>>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>>> >>> web.TradeServletAction.doLogin
>>>>>> >>> <http://web.TradeServletAction.doLogin>
>>>>>> (TradeServletAction.java:364)
>>>>>> >>> at org.apache.geronimo.samples.daytrader .
>>>>>> >>> web.TradeAppServlet.performTask
>>>>>> >>> <http://web.TradeAppServlet.performTask>
>>>>>> (TradeAppServlet.java:126)
>>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>>> >>> web.TradeAppServlet.doPost
>>>>>> >>> <http://web.TradeAppServlet.doPost>
>>>>>> (TradeAppServlet.java :91)
>>>>>> >>> at javax.servlet.http.HttpServlet.service
>>>>>> >>> (HttpServlet.java:617)
>>>>>> >>> at
>>>>>> >>> javax.servlet.http.HttpServlet.service
>>>>>> (HttpServlet.java :690)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>>> >>> (ApplicationFilterChain.java:252)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>>> >>> (ApplicationFilterChain.java:173)
>>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>>> >>> web.OrdersAlertFilter.doFilter
>>>>>> >>> <http://web.OrdersAlertFilter.doFilter>
>>>>>> (OrdersAlertFilter.java:91)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>>> (ApplicationFilterChain.java
>>>>>> >>> :202)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>>> >>> (ApplicationFilterChain.java :173)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.StandardWrapperValve.invoke
>>>>>> (StandardWrapperValve.java:213)
>>>>>> >>> at
>>>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>>>> >>> (StandardContextValve.java:178)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
>>>>>> (DefaultSubjectValve.java:56)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.tomcat.GeronimoStandardContext
>>>>>> $SystemMethodValve.invoke(GeronimoStandardContext.java
>>>>>> >>> :328)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>>>>> (GeronimoBeforeAfterValve.java:47)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.StandardHostValve.invoke
>>>>>> (StandardHostValve.java:126)
>>>>>> >>> at
>>>>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>>>>> >>> (ErrorReportValve.java:105)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.StandardEngineValve.invoke
>>>>>> (StandardEngineValve.java:107)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.valves.AccessLogValve.invoke
>>>>>> (AccessLogValve.java:541)
>>>>>> >>> at
>>>>>> org.apache.catalina.connector.CoyoteAdapter.service
>>>>>> >>> (CoyoteAdapter.java :148)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.coyote.http11.Http11Processor.process
>>>>>> (Http11Processor.java:869)
>>>>>> >>> at
>>>>>> >>> org.apache.coyote.http11.Http11BaseProtocol
>>>>>> $Http11ConnectionHandler.processConnection
>>>>>> (Http11BaseProtocol.java
>>>>>> >>> :667)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
>>>>>> (PoolTcpEndpoint.java:527)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
>>>>>> (LeaderFollowerWorkerThread.java:80)
>>>>>> >>> at
>>>>>> >>> org.apache.tomcat.util.threads.ThreadPool
>>>>>> $ControlRunnable.run
>>>>>> >>> (ThreadPool.java:684)
>>>>>> >>> at java.lang.Thread.run(Thread.java:797)
>>>>>> >>>
>>>>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>>>>> <ma...@planet57.com>
>>>>>> >>> <mailto:jason@planet57.com
>>>>>> <ma...@planet57.com>>> wrote:
>>>>>> >>>
>>>>>> >>> Aight, no worries. I still don't fully
>>>>>> understand
>>>>>> all
>>>>>> >>> that plugin stuff... yet ;-)
>>>>>> >>>
>>>>>> >>> --jason
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>>> The change I have cued up replaces "
>>>>>> 1.2-SNAPSHOT" with
>>>>>> >>>> " 1.2" for all the catalog entries. So
>>>>>> it would
>>>>>> break
>>>>>> >>>> anyone using the Geronimo plugin repo from a
>>>>>> >>>> 1.2-SNAPSHOT server (maybe not a huge
>>>>>> deal). Also,
>>>>>> >>>> I've tested the catalog updates by
>>>>>> looping http
>>>>>> >>>> requests to repo1.maven.org/maven2
>>>>>> <http://repo1.maven.org/maven2>
>>>>>> >>>> <http://repo1.maven.org/maven2> back to
>>>>>> my local
>>>>>> maven
>>>>>> >>>> repo. So I've made some assumptions
>>>>>> about the repo
>>>>>> >>>> layout that should probably be verified.
>>>>>> >>>>
>>>>>> >>>> Best wishes,
>>>>>> >>>> Paul
>>>>>> >>>>
>>>>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon
>>>>>> wrote:
>>>>>> >>>>
>>>>>> >>>>> Will it hurt anything to commit it now?
>>>>>> Or will it
>>>>>> >>>>> break things?
>>>>>> >>>>>
>>>>>> >>>>> --jason
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan
>>>>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn
>>>>>> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>>> I couldn't do much with the framework
>>>>>> assembly
>>>>>> as it
>>>>>> >>>>>>> requires a plugin repository with 1.2
>>>>>> plugins and
>>>>>> >>>>>>> AFAIK there is no such plugin
>>>>>> repository available
>>>>>> >>>>>>> yet. Will you be making the plugins
>>>>>> available for
>>>>>> >>>>>>> 1.2 as you make the release
>>>>>> available? If
>>>>>> not, then
>>>>>> >>>>>>> perhaps we shouldn't include the
>>>>>> framework
>>>>>> assembly
>>>>>> >>>>>>> in the distribution.
>>>>>> >>>>>>
>>>>>> >>>>>> I updated the plugin catalog stuff in
>>>>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2
>>>>>> locally
>>>>>> and ran
>>>>>> >>>>>> some quick tests of plugin download &
>>>>>> install from
>>>>>> >>>>>> maven repo. I'm ready to commit if/
>>>>>> when the 1.2
>>>>>> >>>>>> artifacts are published to central.
>>>>>> >>>>>>
>>>>>> >>>>>> Best wishes,
>>>>>> >>>>>> Paul
>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> --
>>>>>> >>> "I say never be complete, I say stop being
>>>>>> perfect, I say
>>>>>> >>> let... lets evolve, let the chips fall where
>>>>>> they may." -
>>>>>> >>> Tyler Durden
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> "I say never be complete, I say stop being perfect,
>>>>>> I say
>>>>>> let...
>>>>>> >> lets evolve, let the chips fall where they may." -
>>>>>> Tyler Durden
>>>>>> >> <geronimo.log>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > "I say never be complete, I say stop being perfect, I
>>>>>> say let...
>>>>>> lets
>>>>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --"I say never be complete, I say stop being perfect, I say
>>>>>> let... lets evolve, let the chips fall where they may." -
>>>>>> Tyler Durden
>>>>> Index: /usr/src/geronimo-1.2/modules/geronimo-connector/src/
>>>>> main/java/org/apache/geronimo/connector/outbound/
>>>>> connectiontracking/ConnectionTrackingCoordinator.java
>>>>> ==================================================================
>>>>> =
>>>>> --- /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>>>> ConnectionTrackingCoordinator.java (revision 526213)
>>>>> +++ /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>>>> ConnectionTrackingCoordinator.java (working copy)
>>>>> @@ -124,7 +124,23 @@
>>>>>
>>>>> // if no connection remain clear context... we
>>>>> could support automatic commit, rollback or exception here
>>>>> if (connections.isEmpty()) {
>>>>> - i.remove();
>>>>> + boolean retry = false;
>>>>> + int numberOfRetries = 0;
>>>>> + do {
>>>>> + try {
>>>>> + i.remove();
>>>>> + } catch
>>>>> (java.util.ConcurrentModificationException ex) {
>>>>> + if (numberOfRetries < 5) {
>>>>> + retry = true;
>>>>> + } else {
>>>>> + retry = false;
>>>>> + }
>>>>> + numberOfRetries += 1;
>>>>> + }
>>>>> + } while (retry);
>>>>> + if (numberOfRetries >= 5) {
>>>>> + throw new ResourceException
>>>>> ("ConcurrentModificationException - Unable to remove resource");
>>>>> + }
>>>>> }
>>>>> }
>>>>> } finally {
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
> Index: modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java
> ===================================================================
> --- modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (revision 526318)
> +++ modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (working copy)
> @@ -16,8 +16,8 @@
> */
> package org.apache.openejb.util;
>
> -import java.util.LinkedList;
> import java.io.Serializable;
> +import java.util.Stack;
>
> import org.apache.openejb.cache.InstanceFactory;
> import org.apache.openejb.cache.InstancePool;
> @@ -30,19 +30,19 @@
> public final class SoftLimitedInstancePool implements
> InstancePool, Serializable {
> private final InstanceFactory factory;
> private final int maxSize;
> - private transient final LinkedList pool;
> + private transient final Stack pool;
>
> public SoftLimitedInstancePool(final InstanceFactory factory,
> final int maxSize) {
> this.factory = factory;
> this.maxSize = maxSize;
> - pool = new LinkedList();
> + pool = new Stack();
> }
>
> public Object acquire() throws Exception {
> // get the instance from the pool if possible
> synchronized (this) {
> if (!pool.isEmpty()) {
> - return pool.removeFirst();
> + return pool.pop();
> }
> }
>
> @@ -55,7 +55,7 @@
> // if we are under the limit put it back in the pool
> at the head
> // this encourages reuse of the same instances to
> improve memory management
> if (pool.size() < maxSize) {
> - pool.addFirst(instance);
> + pool.push(instance);
> return true;
> }
> }
> @@ -84,7 +84,7 @@
> synchronized (this) {
> // add this new instance to the end
> // we prefer other users get older instances first
> - pool.addLast(instance);
> + pool.insertElementAt(instance, 0);
> }
> }
>
Re: [discuss] Release Geronimo 1.2
Posted by David Jencks <da...@yahoo.com>.
SoftLimitedInstancePool looks to me as if it has adequate
synchronization without Jay's patch, so I think the problem is most
likely elsewhere. At this point I have no idea where.
thanks
david jencks
On Apr 7, 2007, at 2:27 PM, Jay D. McHugh wrote:
> I think I forgot to attach it (of course, the one that is probably
> right).
>
> Hopefully I'll remember now (but just in case here it is inline):
>
> Index: modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java
> ===================================================================
> --- modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (revision 526318)
> +++ modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (working copy)
> @@ -16,8 +16,8 @@
> */
> package org.apache.openejb.util;
>
> -import java.util.LinkedList;
> import java.io.Serializable;
> +import java.util.Stack;
>
> import org.apache.openejb.cache.InstanceFactory;
> import org.apache.openejb.cache.InstancePool;
> @@ -30,19 +30,19 @@
> public final class SoftLimitedInstancePool implements InstancePool,
> Serializable {
> private final InstanceFactory factory;
> private final int maxSize;
> - private transient final LinkedList pool;
> + private transient final Stack pool;
>
> public SoftLimitedInstancePool(final InstanceFactory factory,
> final int maxSize) {
> this.factory = factory;
> this.maxSize = maxSize;
> - pool = new LinkedList();
> + pool = new Stack();
> }
>
> public Object acquire() throws Exception {
> // get the instance from the pool if possible
> synchronized (this) {
> if (!pool.isEmpty()) {
> - return pool.removeFirst();
> + return pool.pop();
> }
> }
>
> @@ -55,7 +55,7 @@
> // if we are under the limit put it back in the pool at
> the head
> // this encourages reuse of the same instances to
> improve memory management
> if (pool.size() < maxSize) {
> - pool.addFirst(instance);
> + pool.push(instance);
> return true;
> }
> }
> @@ -84,7 +84,7 @@
> synchronized (this) {
> // add this new instance to the end
> // we prefer other users get older instances first
> - pool.addLast(instance);
> + pool.insertElementAt(instance, 0);
> }
> }
>
>
>
> Jay
>
> David Jencks wrote:
>> I think the mailing list removed your patch... anyway I don't see
>> it. Can you attach it to a jira or include it inline?
>>
>> thanks
>> david jencks
>>
>> On Apr 6, 2007, at 8:16 PM, Jay D. McHugh wrote:
>>
>>> Whew!
>>>
>>> Maybe now (I ran the openejb tests this time)
>>>
>>> From what I understand, java.util.Stack is internally sychronized
>>> since it is an extension of Vector which is synchronized.
>>>
>>> So, here is a patch that replaces the LinkedList with a Stack.
>>>
>>> It does pass the OpenEJB tests and will hopefully stand up under
>>> stress with daytrader under load.
>>>
>>> Sorry about the previous noise - I'm anxious to get G1.2 out so
>>> that everyone can get back to G2 - Plus, this same issue will
>>> need to be fixed in OpenEJB 3 if this corrects the problem.
>>>
>>> Anyway, hopefully this will get 1.2 closer to the door,
>>>
>>>
>>> Jay
>>>
>>> David Jencks wrote:
>>>> I don't think this is acceptable. There should be only one
>>>> thread working with the context at a time. Either this
>>>> exception is caused by modifying the collection in the same
>>>> thread in which case we can fix it easily or it is caused by
>>>> more than one thread having access to a context at once. Since
>>>> by my reading of the code this is a context attached to a
>>>> stateless session bean instance, that would mean that more than
>>>> one thread is using a stateless session bean instance at once,
>>>> which is definitely cause to -1 the release.
>>>>
>>>> I hope there's another possibility I haven't thought of..... but
>>>> hiding the problem is not acceptable unless we really understand
>>>> what is going on and are really convinced it's harmless.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>>>>
>>>>> Chris (do you go by Chris or Christopher?),
>>>>>
>>>>> Here is a patch that I just wrote that allows the exit routine
>>>>> of ConnectionTrackingCoordinator to finish cleanly after a
>>>>> number (5) of attempts at removing the resource.
>>>>>
>>>>> If it fails after five tries, then the routine exits and throws
>>>>> a ResourceException (that will hopefully be caught further up
>>>>> the stack).
>>>>>
>>>>> Would you like to try it to see if it solves your concurrency
>>>>> problem?
>>>>>
>>>>> Jay
>>>>>
>>>>> Christopher Blythe wrote:
>>>>>> Doubtful... everything tested fine under light browser based
>>>>>> testing. As the exception suggests, this is a concurrency
>>>>>> problem that you would only hit under load.
>>>>>>
>>>>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>>>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>>>>
>>>>>> If Matt had no problem deploying and testing DT, could it
>>>>>> be a Java
>>>>>> version or classpath issue?
>>>>>>
>>>>>> That could explain the difference in the exception during
>>>>>> deployment
>>>>>> (and the problems during deployment could possibly explain
>>>>>> the run
>>>>>> time
>>>>>> problems).
>>>>>>
>>>>>> Jay
>>>>>>
>>>>>> Christopher Blythe wrote:
>>>>>> > I use a commercial load driving tool... FYI, I'm fairly
>>>>>> certain that
>>>>>> > G-2.0 has the same issue.
>>>>>> >
>>>>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>
>>>>>> > <mailto:david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>>>
>>>>>> wrote:
>>>>>> >
>>>>>> > I think we need to figure out why the
>>>>>> > concurrentModificationException is happening before we
>>>>>> release. I
>>>>>> > think that one possible reason is that we are
>>>>>> multithreading
>>>>>> > stateless session bean instances. I hope this isn't
>>>>>> the
>>>>>> cause....
>>>>>> > but IMO we need to find out.
>>>>>> >
>>>>>> > Chris, how do you run the several clients? manually
>>>>>> or with
>>>>>> a tool?
>>>>>> >
>>>>>> > thanks
>>>>>> > david jencks
>>>>>> >
>>>>>> >
>>>>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>>>>> >
>>>>>> >> Gave it a shot... no luck. As soon as I started 2
>>>>>> clients, the
>>>>>> >> same exceptions started to pile up. I have attached
>>>>>> the
>>>>>> >> geronimo.log. Also, noticed the following exception
>>>>>> during
>>>>>> startup.
>>>>>> >>
>>>>>> >> 14:05:00,640 ERROR [TransportConnector] Could not
>>>>>> accept
>>>>>> >> connection from /127.0.0.1:28428:
>>>>>> java.io.IOException: Wire
>>>>>> >> format negociation timeout: peer did not send his
>>>>>> wire format.
>>>>>> >> java.io.IOException: Wire format negociation
>>>>>> timeout: peer did
>>>>>> >> not send his wire format.
>>>>>> >> at
>>>>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>>>>> >> (WireFormatNegotiator.java :88)
>>>>>> >> at
>>>>>> >>
>>>>>> org.apache.activemq.transport.MutexTransport.oneway
>>>>>> (MutexTransport.java:47)
>>>>>> >> at
>>>>>> org.apache.activemq.broker.TransportConnection.dispatch
>>>>>> >> (TransportConnection.java :1138)
>>>>>> >> at
>>>>>> >>
>>>>>> org.apache.activemq.broker.TransportConnection.processDispatch
>>>>>> (TransportConnection.java:805)
>>>>>> >> at
>>>>>> >> org.apache.activemq.broker.TransportConnection.start
>>>>>> (TransportConnection.java
>>>>>> >> :885)
>>>>>> >> at org.apache.activemq.broker.TransportConnector
>>>>>> $1.onAccept
>>>>>> >> (TransportConnector.java:148)
>>>>>> >> at
>>>>>> >>
>>>>>> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>>>>> (TcpTransportServer.java:167)
>>>>>> >> at java.lang.Thread.run (Thread.java:797)
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>>>>> <ma...@hogstrom.org>
>>>>>> >> <mailto:matt@hogstrom.org
>>>>>> <ma...@hogstrom.org>>> wrote:
>>>>>> >>
>>>>>> >> Only a very light load from a few browsers.
>>>>>> One thing
>>>>>> to try
>>>>>> >> is to increase the number of SLSBs in the pool.
>>>>>> >>
>>>>>> >> Can you add
>>>>>> >>
>>>>>> >> <session>
>>>>>> >> <ejb-name>TradeJDBC</ejb-name>
>>>>>> >> <jndi-name>ejb/TradeJDBC</
>>>>>> jndi-name>
>>>>>> >> <cache-size>100</cache-size>
>>>>>> >> </session>
>>>>>> >>
>>>>>> >> to your plan and redeploy. I added some
>>>>>> support for
>>>>>> multiple
>>>>>> >> SLSBs in a pool for 1.2 which we did not have
>>>>>> before. This
>>>>>> >> will hopefully make it better and not worse :)
>>>>>> >>
>>>>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe
>>>>>> wrote:
>>>>>> >>
>>>>>> >>> Matt...
>>>>>> >>>
>>>>>> >>> You mentioned that you deployed DayTrader
>>>>>> 1.2... did you
>>>>>> >>> happen to run it under load? JDBC/Direct mode
>>>>>> looks good;
>>>>>> >>> however, I am still seeing
>>>>>> ConcurrentModificationExceptions
>>>>>> >>> while attempting to run more than 1 client in
>>>>>> Session
>>>>>> Direct
>>>>>> >>> mode (
>>>>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>>>>> >>> These exceptions are thrown throughout the
>>>>>> duration of the
>>>>>> >>> run. FYI - I deployed the same ear on Geronimo
>>>>>> 1.1.1 and
>>>>>> >>> didn't have a problem scaling up the users for
>>>>>> Session
>>>>>> >>> Direct mode.
>>>>>> >>>
>>>>>> >>> java.util.ConcurrentModificationException
>>>>>> >>> at
>>>>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connect
>>>>>> ionTrackingCoordinator.exit
>>>>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connect
>>>>>> ionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
>>>>>> (<generated>)
>>>>>>
>>>>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>>>>> >>> (FastMethod.java :53)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>>>> (FastMethodInvoker.java:38)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>>>> (GBeanOperation.java:122)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>>>> >>> (GBeanInstance.java:820)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>>>>>> (RawInvoker.java:57)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>>>> (RawOperationInvoker.java:35)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>>>> >>> ( ProxyMethodInterceptor.java:96)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connect
>>>>>> ionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>>>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>>>>> (SystemExceptionInterceptor.java:35)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke
>>>>>> (DefaultSubjectInterceptor.java
>>>>>> >>> :49)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
>>>>>> (DefaultStatelessEjbContainer.java:178)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$
>>>>>> $FastClassByCGLIB$$7ad7a562.invoke
>>>>>> (<generated>)
>>>>>> >>>
>>>>>> >>> at
>>>>>> >>> net.sf.cglib.reflect.FastMethod.invoke
>>>>>> (FastMethod.java:53)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>>>> (FastMethodInvoker.java:38)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>>>> >>> (GBeanOperation.java:122)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>>>> (GBeanInstance.java:820)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>>>>>> (RawInvoker.java
>>>>>> :57)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>>>> >>> (RawOperationInvoker.java:35)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>>>> (ProxyMethodInterceptor.java:96)
>>>>>> >>> at
>>>>>> >>> org.apache.openejb.StatelessEjbContainer$
>>>>>> $EnhancerByCGLIB$$5c554f35.invoke
>>>>>>
>>>>>> >>> (<generated>)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.AbstractEjbDeployment.invoke
>>>>>> (AbstractEjbDeployment.java:195)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept
>>>>>> (EJBMethodInterceptor.java:145)
>>>>>> >>> at
>>>>>> >>> org.apache.openejb.proxy.SessionEJBObject$
>>>>>> $EnhancerByCGLIB$$f5a9c1b2.login
>>>>>> >>> (<generated>)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.samples.daytrader.TradeAction.login
>>>>>> (TradeAction.java:449)
>>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>>> >>> web.TradeServletAction.doLogin
>>>>>> >>> <http://web.TradeServletAction.doLogin>
>>>>>> (TradeServletAction.java:364)
>>>>>> >>> at org.apache.geronimo.samples.daytrader .
>>>>>> >>> web.TradeAppServlet.performTask
>>>>>> >>> <http://web.TradeAppServlet.performTask>
>>>>>> (TradeAppServlet.java:126)
>>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>>> >>> web.TradeAppServlet.doPost
>>>>>> >>> <http://web.TradeAppServlet.doPost>
>>>>>> (TradeAppServlet.java :91)
>>>>>> >>> at javax.servlet.http.HttpServlet.service
>>>>>> >>> (HttpServlet.java:617)
>>>>>> >>> at
>>>>>> >>> javax.servlet.http.HttpServlet.service
>>>>>> (HttpServlet.java :690)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>>> >>> (ApplicationFilterChain.java:252)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>>> >>> (ApplicationFilterChain.java:173)
>>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>>> >>> web.OrdersAlertFilter.doFilter
>>>>>> >>> <http://web.OrdersAlertFilter.doFilter>
>>>>>> (OrdersAlertFilter.java:91)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>>> (ApplicationFilterChain.java
>>>>>> >>> :202)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>>> >>> (ApplicationFilterChain.java :173)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.StandardWrapperValve.invoke
>>>>>> (StandardWrapperValve.java:213)
>>>>>> >>> at
>>>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>>>> >>> (StandardContextValve.java:178)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
>>>>>> (DefaultSubjectValve.java:56)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.tomcat.GeronimoStandardContext
>>>>>> $SystemMethodValve.invoke(GeronimoStandardContext.java
>>>>>> >>> :328)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>>>>> (GeronimoBeforeAfterValve.java:47)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.StandardHostValve.invoke
>>>>>> (StandardHostValve.java:126)
>>>>>> >>> at
>>>>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>>>>> >>> (ErrorReportValve.java:105)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.core.StandardEngineValve.invoke
>>>>>> (StandardEngineValve.java:107)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.catalina.valves.AccessLogValve.invoke
>>>>>> (AccessLogValve.java:541)
>>>>>> >>> at
>>>>>> org.apache.catalina.connector.CoyoteAdapter.service
>>>>>> >>> (CoyoteAdapter.java :148)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.coyote.http11.Http11Processor.process
>>>>>> (Http11Processor.java:869)
>>>>>> >>> at
>>>>>> >>> org.apache.coyote.http11.Http11BaseProtocol
>>>>>> $Http11ConnectionHandler.processConnection
>>>>>> (Http11BaseProtocol.java
>>>>>> >>> :667)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
>>>>>> (PoolTcpEndpoint.java:527)
>>>>>> >>> at
>>>>>> >>>
>>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
>>>>>> (LeaderFollowerWorkerThread.java:80)
>>>>>> >>> at
>>>>>> >>> org.apache.tomcat.util.threads.ThreadPool
>>>>>> $ControlRunnable.run
>>>>>> >>> (ThreadPool.java:684)
>>>>>> >>> at java.lang.Thread.run(Thread.java:797)
>>>>>> >>>
>>>>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>>>>> <ma...@planet57.com>
>>>>>> >>> <mailto:jason@planet57.com
>>>>>> <ma...@planet57.com>>> wrote:
>>>>>> >>>
>>>>>> >>> Aight, no worries. I still don't fully
>>>>>> understand
>>>>>> all
>>>>>> >>> that plugin stuff... yet ;-)
>>>>>> >>>
>>>>>> >>> --jason
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>>> The change I have cued up replaces "
>>>>>> 1.2-SNAPSHOT" with
>>>>>> >>>> " 1.2" for all the catalog entries. So
>>>>>> it would
>>>>>> break
>>>>>> >>>> anyone using the Geronimo plugin repo from a
>>>>>> >>>> 1.2-SNAPSHOT server (maybe not a huge
>>>>>> deal). Also,
>>>>>> >>>> I've tested the catalog updates by
>>>>>> looping http
>>>>>> >>>> requests to repo1.maven.org/maven2
>>>>>> <http://repo1.maven.org/maven2>
>>>>>> >>>> <http://repo1.maven.org/maven2> back to
>>>>>> my local
>>>>>> maven
>>>>>> >>>> repo. So I've made some assumptions
>>>>>> about the repo
>>>>>> >>>> layout that should probably be verified.
>>>>>> >>>>
>>>>>> >>>> Best wishes,
>>>>>> >>>> Paul
>>>>>> >>>>
>>>>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon
>>>>>> wrote:
>>>>>> >>>>
>>>>>> >>>>> Will it hurt anything to commit it now?
>>>>>> Or will it
>>>>>> >>>>> break things?
>>>>>> >>>>>
>>>>>> >>>>> --jason
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan
>>>>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn
>>>>>> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>>> I couldn't do much with the framework
>>>>>> assembly
>>>>>> as it
>>>>>> >>>>>>> requires a plugin repository with 1.2
>>>>>> plugins and
>>>>>> >>>>>>> AFAIK there is no such plugin
>>>>>> repository available
>>>>>> >>>>>>> yet. Will you be making the plugins
>>>>>> available for
>>>>>> >>>>>>> 1.2 as you make the release
>>>>>> available? If
>>>>>> not, then
>>>>>> >>>>>>> perhaps we shouldn't include the
>>>>>> framework
>>>>>> assembly
>>>>>> >>>>>>> in the distribution.
>>>>>> >>>>>>
>>>>>> >>>>>> I updated the plugin catalog stuff in
>>>>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2
>>>>>> locally
>>>>>> and ran
>>>>>> >>>>>> some quick tests of plugin download &
>>>>>> install from
>>>>>> >>>>>> maven repo. I'm ready to commit if/
>>>>>> when the 1.2
>>>>>> >>>>>> artifacts are published to central.
>>>>>> >>>>>>
>>>>>> >>>>>> Best wishes,
>>>>>> >>>>>> Paul
>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> --
>>>>>> >>> "I say never be complete, I say stop being
>>>>>> perfect, I say
>>>>>> >>> let... lets evolve, let the chips fall where
>>>>>> they may." -
>>>>>> >>> Tyler Durden
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> "I say never be complete, I say stop being perfect,
>>>>>> I say
>>>>>> let...
>>>>>> >> lets evolve, let the chips fall where they may." -
>>>>>> Tyler Durden
>>>>>> >> <geronimo.log>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > "I say never be complete, I say stop being perfect, I
>>>>>> say let...
>>>>>> lets
>>>>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --"I say never be complete, I say stop being perfect, I say
>>>>>> let... lets evolve, let the chips fall where they may." -
>>>>>> Tyler Durden
>>>>> Index: /usr/src/geronimo-1.2/modules/geronimo-connector/src/
>>>>> main/java/org/apache/geronimo/connector/outbound/
>>>>> connectiontracking/ConnectionTrackingCoordinator.java
>>>>> ==================================================================
>>>>> =
>>>>> --- /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>>>> ConnectionTrackingCoordinator.java (revision 526213)
>>>>> +++ /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>>>> ConnectionTrackingCoordinator.java (working copy)
>>>>> @@ -124,7 +124,23 @@
>>>>>
>>>>> // if no connection remain clear context... we
>>>>> could support automatic commit, rollback or exception here
>>>>> if (connections.isEmpty()) {
>>>>> - i.remove();
>>>>> + boolean retry = false;
>>>>> + int numberOfRetries = 0;
>>>>> + do {
>>>>> + try {
>>>>> + i.remove();
>>>>> + } catch
>>>>> (java.util.ConcurrentModificationException ex) {
>>>>> + if (numberOfRetries < 5) {
>>>>> + retry = true;
>>>>> + } else {
>>>>> + retry = false;
>>>>> + }
>>>>> + numberOfRetries += 1;
>>>>> + }
>>>>> + } while (retry);
>>>>> + if (numberOfRetries >= 5) {
>>>>> + throw new ResourceException
>>>>> ("ConcurrentModificationException - Unable to remove resource");
>>>>> + }
>>>>> }
>>>>> }
>>>>> } finally {
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
> Index: modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java
> ===================================================================
> --- modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (revision 526318)
> +++ modules/openejb-core/src/main/java/org/apache/openejb/util/
> SoftLimitedInstancePool.java (working copy)
> @@ -16,8 +16,8 @@
> */
> package org.apache.openejb.util;
>
> -import java.util.LinkedList;
> import java.io.Serializable;
> +import java.util.Stack;
>
> import org.apache.openejb.cache.InstanceFactory;
> import org.apache.openejb.cache.InstancePool;
> @@ -30,19 +30,19 @@
> public final class SoftLimitedInstancePool implements
> InstancePool, Serializable {
> private final InstanceFactory factory;
> private final int maxSize;
> - private transient final LinkedList pool;
> + private transient final Stack pool;
>
> public SoftLimitedInstancePool(final InstanceFactory factory,
> final int maxSize) {
> this.factory = factory;
> this.maxSize = maxSize;
> - pool = new LinkedList();
> + pool = new Stack();
> }
>
> public Object acquire() throws Exception {
> // get the instance from the pool if possible
> synchronized (this) {
> if (!pool.isEmpty()) {
> - return pool.removeFirst();
> + return pool.pop();
> }
> }
>
> @@ -55,7 +55,7 @@
> // if we are under the limit put it back in the pool
> at the head
> // this encourages reuse of the same instances to
> improve memory management
> if (pool.size() < maxSize) {
> - pool.addFirst(instance);
> + pool.push(instance);
> return true;
> }
> }
> @@ -84,7 +84,7 @@
> synchronized (this) {
> // add this new instance to the end
> // we prefer other users get older instances first
> - pool.addLast(instance);
> + pool.insertElementAt(instance, 0);
> }
> }
>
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
I think I forgot to attach it (of course, the one that is probably right).
Hopefully I'll remember now (but just in case here it is inline):
Index:
modules/openejb-core/src/main/java/org/apache/openejb/util/SoftLimitedInstancePool.java
===================================================================
---
modules/openejb-core/src/main/java/org/apache/openejb/util/SoftLimitedInstancePool.java
(revision 526318)
+++
modules/openejb-core/src/main/java/org/apache/openejb/util/SoftLimitedInstancePool.java
(working copy)
@@ -16,8 +16,8 @@
*/
package org.apache.openejb.util;
-import java.util.LinkedList;
import java.io.Serializable;
+import java.util.Stack;
import org.apache.openejb.cache.InstanceFactory;
import org.apache.openejb.cache.InstancePool;
@@ -30,19 +30,19 @@
public final class SoftLimitedInstancePool implements InstancePool,
Serializable {
private final InstanceFactory factory;
private final int maxSize;
- private transient final LinkedList pool;
+ private transient final Stack pool;
public SoftLimitedInstancePool(final InstanceFactory factory, final
int maxSize) {
this.factory = factory;
this.maxSize = maxSize;
- pool = new LinkedList();
+ pool = new Stack();
}
public Object acquire() throws Exception {
// get the instance from the pool if possible
synchronized (this) {
if (!pool.isEmpty()) {
- return pool.removeFirst();
+ return pool.pop();
}
}
@@ -55,7 +55,7 @@
// if we are under the limit put it back in the pool at the
head
// this encourages reuse of the same instances to improve
memory management
if (pool.size() < maxSize) {
- pool.addFirst(instance);
+ pool.push(instance);
return true;
}
}
@@ -84,7 +84,7 @@
synchronized (this) {
// add this new instance to the end
// we prefer other users get older instances first
- pool.addLast(instance);
+ pool.insertElementAt(instance, 0);
}
}
Jay
David Jencks wrote:
> I think the mailing list removed your patch... anyway I don't see it.
> Can you attach it to a jira or include it inline?
>
> thanks
> david jencks
>
> On Apr 6, 2007, at 8:16 PM, Jay D. McHugh wrote:
>
>> Whew!
>>
>> Maybe now (I ran the openejb tests this time)
>>
>> From what I understand, java.util.Stack is internally sychronized
>> since it is an extension of Vector which is synchronized.
>>
>> So, here is a patch that replaces the LinkedList with a Stack.
>>
>> It does pass the OpenEJB tests and will hopefully stand up under
>> stress with daytrader under load.
>>
>> Sorry about the previous noise - I'm anxious to get G1.2 out so that
>> everyone can get back to G2 - Plus, this same issue will need to be
>> fixed in OpenEJB 3 if this corrects the problem.
>>
>> Anyway, hopefully this will get 1.2 closer to the door,
>>
>>
>> Jay
>>
>> David Jencks wrote:
>>> I don't think this is acceptable. There should be only one thread
>>> working with the context at a time. Either this exception is caused
>>> by modifying the collection in the same thread in which case we can
>>> fix it easily or it is caused by more than one thread having access
>>> to a context at once. Since by my reading of the code this is a
>>> context attached to a stateless session bean instance, that would
>>> mean that more than one thread is using a stateless session bean
>>> instance at once, which is definitely cause to -1 the release.
>>>
>>> I hope there's another possibility I haven't thought of..... but
>>> hiding the problem is not acceptable unless we really understand
>>> what is going on and are really convinced it's harmless.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>>>
>>>> Chris (do you go by Chris or Christopher?),
>>>>
>>>> Here is a patch that I just wrote that allows the exit routine of
>>>> ConnectionTrackingCoordinator to finish cleanly after a number (5)
>>>> of attempts at removing the resource.
>>>>
>>>> If it fails after five tries, then the routine exits and throws a
>>>> ResourceException (that will hopefully be caught further up the
>>>> stack).
>>>>
>>>> Would you like to try it to see if it solves your concurrency problem?
>>>>
>>>> Jay
>>>>
>>>> Christopher Blythe wrote:
>>>>> Doubtful... everything tested fine under light browser based
>>>>> testing. As the exception suggests, this is a concurrency problem
>>>>> that you would only hit under load.
>>>>>
>>>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>>>
>>>>> If Matt had no problem deploying and testing DT, could it be a
>>>>> Java
>>>>> version or classpath issue?
>>>>>
>>>>> That could explain the difference in the exception during
>>>>> deployment
>>>>> (and the problems during deployment could possibly explain the
>>>>> run
>>>>> time
>>>>> problems).
>>>>>
>>>>> Jay
>>>>>
>>>>> Christopher Blythe wrote:
>>>>> > I use a commercial load driving tool... FYI, I'm fairly
>>>>> certain that
>>>>> > G-2.0 has the same issue.
>>>>> >
>>>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>>>> <ma...@yahoo.com>
>>>>> > <mailto:david_jencks@yahoo.com
>>>>> <ma...@yahoo.com>>>
>>>>> wrote:
>>>>> >
>>>>> > I think we need to figure out why the
>>>>> > concurrentModificationException is happening before we
>>>>> release. I
>>>>> > think that one possible reason is that we are
>>>>> multithreading
>>>>> > stateless session bean instances. I hope this isn't the
>>>>> cause....
>>>>> > but IMO we need to find out.
>>>>> >
>>>>> > Chris, how do you run the several clients? manually or
>>>>> with
>>>>> a tool?
>>>>> >
>>>>> > thanks
>>>>> > david jencks
>>>>> >
>>>>> >
>>>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>>>> >
>>>>> >> Gave it a shot... no luck. As soon as I started 2
>>>>> clients, the
>>>>> >> same exceptions started to pile up. I have attached the
>>>>> >> geronimo.log. Also, noticed the following exception during
>>>>> startup.
>>>>> >>
>>>>> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
>>>>> >> connection from /127.0.0.1:28428: java.io.IOException:
>>>>> Wire
>>>>> >> format negociation timeout: peer did not send his wire
>>>>> format.
>>>>> >> java.io.IOException: Wire format negociation timeout:
>>>>> peer did
>>>>> >> not send his wire format.
>>>>> >> at
>>>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>>>> >> (WireFormatNegotiator.java :88)
>>>>> >> at
>>>>> >>
>>>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
>>>>>
>>>>> >> at
>>>>> org.apache.activemq.broker.TransportConnection.dispatch
>>>>> >> (TransportConnection.java :1138)
>>>>> >> at
>>>>> >>
>>>>> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
>>>>>
>>>>> >> at
>>>>> >> org.apache.activemq.broker.TransportConnection.start
>>>>> (TransportConnection.java
>>>>> >> :885)
>>>>> >> at
>>>>> org.apache.activemq.broker.TransportConnector$1.onAccept
>>>>> >> (TransportConnector.java:148)
>>>>> >> at
>>>>> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>>>> (TcpTransportServer.java:167)
>>>>> >> at java.lang.Thread.run (Thread.java:797)
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>>>> <ma...@hogstrom.org>
>>>>> >> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>>
>>>>> wrote:
>>>>> >>
>>>>> >> Only a very light load from a few browsers. One thing
>>>>> to try
>>>>> >> is to increase the number of SLSBs in the pool.
>>>>> >>
>>>>> >> Can you add
>>>>> >>
>>>>> >> <session>
>>>>> >> <ejb-name>TradeJDBC</ejb-name>
>>>>> >>
>>>>> <jndi-name>ejb/TradeJDBC</jndi-name>
>>>>> >> <cache-size>100</cache-size>
>>>>> >> </session>
>>>>> >>
>>>>> >> to your plan and redeploy. I added some support for
>>>>> multiple
>>>>> >> SLSBs in a pool for 1.2 which we did not have
>>>>> before. This
>>>>> >> will hopefully make it better and not worse :)
>>>>> >>
>>>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>>>>> >>
>>>>> >>> Matt...
>>>>> >>>
>>>>> >>> You mentioned that you deployed DayTrader 1.2...
>>>>> did you
>>>>> >>> happen to run it under load? JDBC/Direct mode
>>>>> looks good;
>>>>> >>> however, I am still seeing
>>>>> ConcurrentModificationExceptions
>>>>> >>> while attempting to run more than 1 client in Session
>>>>> Direct
>>>>> >>> mode (
>>>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>>>> >>> These exceptions are thrown throughout the
>>>>> duration of the
>>>>> >>> run. FYI - I deployed the same ear on Geronimo
>>>>> 1.1.1 and
>>>>> >>> didn't have a problem scaling up the users for
>>>>> Session
>>>>> >>> Direct mode.
>>>>> >>>
>>>>> >>> java.util.ConcurrentModificationException
>>>>> >>> at
>>>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
>>>>>
>>>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>>>>>
>>>>>
>>>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>>>> >>> (FastMethod.java :53)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>>> (FastMethodInvoker.java:38)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>>> >>> (GBeanInstance.java:820)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>>> >>> ( ProxyMethodInterceptor.java:96)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>>>> >>> at
>>>>> >>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>>>> (SystemExceptionInterceptor.java:35)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java
>>>>>
>>>>> >>> :49)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java:178)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
>>>>>
>>>>> (<generated>)
>>>>> >>>
>>>>> >>> at
>>>>> >>>
>>>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>>> (FastMethodInvoker.java:38)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>>> >>> (GBeanOperation.java:122)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
>>>>> :57)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>>> >>> (RawOperationInvoker.java:35)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
>>>>>
>>>>>
>>>>> >>> (<generated>)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
>>>>>
>>>>> >>> (<generated>)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java:449)
>>>>>
>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>> >>> web.TradeServletAction.doLogin
>>>>> >>>
>>>>> <http://web.TradeServletAction.doLogin>(TradeServletAction.java:364)
>>>>> >>> at org.apache.geronimo.samples.daytrader .
>>>>> >>> web.TradeAppServlet.performTask
>>>>> >>>
>>>>> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java:126)
>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>> >>> web.TradeAppServlet.doPost
>>>>> >>>
>>>>> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java :91)
>>>>> >>> at javax.servlet.http.HttpServlet.service
>>>>> >>> (HttpServlet.java:617)
>>>>> >>> at
>>>>> >>>
>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java :690)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>> >>> (ApplicationFilterChain.java:252)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>> >>> (ApplicationFilterChain.java:173)
>>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>>> >>> web.OrdersAlertFilter.doFilter
>>>>> >>>
>>>>> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java:91)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>> (ApplicationFilterChain.java
>>>>> >>> :202)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>> >>> (ApplicationFilterChain.java :173)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>>>
>>>>> >>> at
>>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>>> >>> (StandardContextValve.java:178)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java
>>>>>
>>>>> >>> :328)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>>>> (GeronimoBeforeAfterValve.java:47)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>>>>>
>>>>> >>> at
>>>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>>>> >>> (ErrorReportValve.java:105)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
>>>>>
>>>>> >>> at
>>>>> org.apache.catalina.connector.CoyoteAdapter.service
>>>>> >>> (CoyoteAdapter.java :148)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
>>>>>
>>>>> (Http11BaseProtocol.java
>>>>> >>> :667)
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>>
>>>>> >>> at
>>>>> >>>
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
>>>>> >>> (ThreadPool.java:684)
>>>>> >>> at java.lang.Thread.run(Thread.java:797)
>>>>> >>>
>>>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>>>> <ma...@planet57.com>
>>>>> >>> <mailto:jason@planet57.com
>>>>> <ma...@planet57.com>>> wrote:
>>>>> >>>
>>>>> >>> Aight, no worries. I still don't fully
>>>>> understand
>>>>> all
>>>>> >>> that plugin stuff... yet ;-)
>>>>> >>>
>>>>> >>> --jason
>>>>> >>>
>>>>> >>>
>>>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>>>> >>>
>>>>> >>>> The change I have cued up replaces "
>>>>> 1.2-SNAPSHOT" with
>>>>> >>>> " 1.2" for all the catalog entries. So it would
>>>>> break
>>>>> >>>> anyone using the Geronimo plugin repo from a
>>>>> >>>> 1.2-SNAPSHOT server (maybe not a huge deal).
>>>>> Also,
>>>>> >>>> I've tested the catalog updates by looping http
>>>>> >>>> requests to repo1.maven.org/maven2
>>>>> <http://repo1.maven.org/maven2>
>>>>> >>>> <http://repo1.maven.org/maven2> back to my local
>>>>> maven
>>>>> >>>> repo. So I've made some assumptions about
>>>>> the repo
>>>>> >>>> layout that should probably be verified.
>>>>> >>>>
>>>>> >>>> Best wishes,
>>>>> >>>> Paul
>>>>> >>>>
>>>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>>>> >>>>
>>>>> >>>>> Will it hurt anything to commit it now? Or
>>>>> will it
>>>>> >>>>> break things?
>>>>> >>>>>
>>>>> >>>>> --jason
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>>>> >>>>>
>>>>> >>>>>>
>>>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>>> >>>>>>
>>>>> >>>>>>> I couldn't do much with the framework
>>>>> assembly
>>>>> as it
>>>>> >>>>>>> requires a plugin repository with 1.2
>>>>> plugins and
>>>>> >>>>>>> AFAIK there is no such plugin repository
>>>>> available
>>>>> >>>>>>> yet. Will you be making the plugins
>>>>> available for
>>>>> >>>>>>> 1.2 as you make the release available? If
>>>>> not, then
>>>>> >>>>>>> perhaps we shouldn't include the framework
>>>>> assembly
>>>>> >>>>>>> in the distribution.
>>>>> >>>>>>
>>>>> >>>>>> I updated the plugin catalog stuff in
>>>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally
>>>>> and ran
>>>>> >>>>>> some quick tests of plugin download &
>>>>> install from
>>>>> >>>>>> maven repo. I'm ready to commit if/when
>>>>> the 1.2
>>>>> >>>>>> artifacts are published to central.
>>>>> >>>>>>
>>>>> >>>>>> Best wishes,
>>>>> >>>>>> Paul
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> "I say never be complete, I say stop being
>>>>> perfect, I say
>>>>> >>> let... lets evolve, let the chips fall where they
>>>>> may." -
>>>>> >>> Tyler Durden
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> "I say never be complete, I say stop being perfect, I say
>>>>> let...
>>>>> >> lets evolve, let the chips fall where they may." -
>>>>> Tyler Durden
>>>>> >> <geronimo.log>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > "I say never be complete, I say stop being perfect, I say
>>>>> let...
>>>>> lets
>>>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --"I say never be complete, I say stop being perfect, I say let...
>>>>> lets evolve, let the chips fall where they may." - Tyler Durden
>>>> Index:
>>>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>>>
>>>> ===================================================================
>>>> ---
>>>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>>> (revision 526213)
>>>> +++
>>>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>>> (working copy)
>>>> @@ -124,7 +124,23 @@
>>>>
>>>> // if no connection remain clear context... we
>>>> could support automatic commit, rollback or exception here
>>>> if (connections.isEmpty()) {
>>>> - i.remove();
>>>> + boolean retry = false;
>>>> + int numberOfRetries = 0;
>>>> + do {
>>>> + try {
>>>> + i.remove();
>>>> + } catch
>>>> (java.util.ConcurrentModificationException ex) {
>>>> + if (numberOfRetries < 5) {
>>>> + retry = true;
>>>> + } else {
>>>> + retry = false;
>>>> + }
>>>> + numberOfRetries += 1;
>>>> + }
>>>> + } while (retry);
>>>> + if (numberOfRetries >= 5) {
>>>> + throw new
>>>> ResourceException("ConcurrentModificationException - Unable to
>>>> remove resource");
>>>> + }
>>>> }
>>>> }
>>>> } finally {
>>>
>>>
>>>
>>>
>
>
>
>
Re: [discuss] Release Geronimo 1.2
Posted by David Jencks <da...@yahoo.com>.
I think the mailing list removed your patch... anyway I don't see
it. Can you attach it to a jira or include it inline?
thanks
david jencks
On Apr 6, 2007, at 8:16 PM, Jay D. McHugh wrote:
> Whew!
>
> Maybe now (I ran the openejb tests this time)
>
> From what I understand, java.util.Stack is internally sychronized
> since it is an extension of Vector which is synchronized.
>
> So, here is a patch that replaces the LinkedList with a Stack.
>
> It does pass the OpenEJB tests and will hopefully stand up under
> stress with daytrader under load.
>
> Sorry about the previous noise - I'm anxious to get G1.2 out so
> that everyone can get back to G2 - Plus, this same issue will need
> to be fixed in OpenEJB 3 if this corrects the problem.
>
> Anyway, hopefully this will get 1.2 closer to the door,
>
>
> Jay
>
> David Jencks wrote:
>> I don't think this is acceptable. There should be only one thread
>> working with the context at a time. Either this exception is
>> caused by modifying the collection in the same thread in which
>> case we can fix it easily or it is caused by more than one thread
>> having access to a context at once. Since by my reading of the
>> code this is a context attached to a stateless session bean
>> instance, that would mean that more than one thread is using a
>> stateless session bean instance at once, which is definitely cause
>> to -1 the release.
>>
>> I hope there's another possibility I haven't thought of..... but
>> hiding the problem is not acceptable unless we really understand
>> what is going on and are really convinced it's harmless.
>>
>> thanks
>> david jencks
>>
>> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>>
>>> Chris (do you go by Chris or Christopher?),
>>>
>>> Here is a patch that I just wrote that allows the exit routine of
>>> ConnectionTrackingCoordinator to finish cleanly after a number
>>> (5) of attempts at removing the resource.
>>>
>>> If it fails after five tries, then the routine exits and throws a
>>> ResourceException (that will hopefully be caught further up the
>>> stack).
>>>
>>> Would you like to try it to see if it solves your concurrency
>>> problem?
>>>
>>> Jay
>>>
>>> Christopher Blythe wrote:
>>>> Doubtful... everything tested fine under light browser based
>>>> testing. As the exception suggests, this is a concurrency
>>>> problem that you would only hit under load.
>>>>
>>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>>
>>>> If Matt had no problem deploying and testing DT, could it be
>>>> a Java
>>>> version or classpath issue?
>>>>
>>>> That could explain the difference in the exception during
>>>> deployment
>>>> (and the problems during deployment could possibly explain
>>>> the run
>>>> time
>>>> problems).
>>>>
>>>> Jay
>>>>
>>>> Christopher Blythe wrote:
>>>> > I use a commercial load driving tool... FYI, I'm fairly
>>>> certain that
>>>> > G-2.0 has the same issue.
>>>> >
>>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>>> <ma...@yahoo.com>
>>>> > <mailto:david_jencks@yahoo.com
>>>> <ma...@yahoo.com>>>
>>>> wrote:
>>>> >
>>>> > I think we need to figure out why the
>>>> > concurrentModificationException is happening before we
>>>> release. I
>>>> > think that one possible reason is that we are
>>>> multithreading
>>>> > stateless session bean instances. I hope this isn't the
>>>> cause....
>>>> > but IMO we need to find out.
>>>> >
>>>> > Chris, how do you run the several clients? manually
>>>> or with
>>>> a tool?
>>>> >
>>>> > thanks
>>>> > david jencks
>>>> >
>>>> >
>>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>>> >
>>>> >> Gave it a shot... no luck. As soon as I started 2
>>>> clients, the
>>>> >> same exceptions started to pile up. I have attached the
>>>> >> geronimo.log. Also, noticed the following exception
>>>> during
>>>> startup.
>>>> >>
>>>> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
>>>> >> connection from /127.0.0.1:28428:
>>>> java.io.IOException: Wire
>>>> >> format negociation timeout: peer did not send his
>>>> wire format.
>>>> >> java.io.IOException: Wire format negociation timeout:
>>>> peer did
>>>> >> not send his wire format.
>>>> >> at
>>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>>> >> (WireFormatNegotiator.java :88)
>>>> >> at
>>>> >> org.apache.activemq.transport.MutexTransport.oneway
>>>> (MutexTransport.java:47)
>>>> >> at
>>>> org.apache.activemq.broker.TransportConnection.dispatch
>>>> >> (TransportConnection.java :1138)
>>>> >> at
>>>> >>
>>>> org.apache.activemq.broker.TransportConnection.processDispatch
>>>> (TransportConnection.java:805)
>>>> >> at
>>>> >> org.apache.activemq.broker.TransportConnection.start
>>>> (TransportConnection.java
>>>> >> :885)
>>>> >> at org.apache.activemq.broker.TransportConnector
>>>> $1.onAccept
>>>> >> (TransportConnector.java:148)
>>>> >> at
>>>> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>>> (TcpTransportServer.java:167)
>>>> >> at java.lang.Thread.run (Thread.java:797)
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>>> <ma...@hogstrom.org>
>>>> >> <mailto:matt@hogstrom.org
>>>> <ma...@hogstrom.org>>> wrote:
>>>> >>
>>>> >> Only a very light load from a few browsers. One
>>>> thing
>>>> to try
>>>> >> is to increase the number of SLSBs in the pool.
>>>> >>
>>>> >> Can you add
>>>> >>
>>>> >> <session>
>>>> >> <ejb-name>TradeJDBC</ejb-name>
>>>> >> <jndi-name>ejb/TradeJDBC</
>>>> jndi-name>
>>>> >> <cache-size>100</cache-size>
>>>> >> </session>
>>>> >>
>>>> >> to your plan and redeploy. I added some support for
>>>> multiple
>>>> >> SLSBs in a pool for 1.2 which we did not have
>>>> before. This
>>>> >> will hopefully make it better and not worse :)
>>>> >>
>>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe
>>>> wrote:
>>>> >>
>>>> >>> Matt...
>>>> >>>
>>>> >>> You mentioned that you deployed DayTrader 1.2...
>>>> did you
>>>> >>> happen to run it under load? JDBC/Direct mode
>>>> looks good;
>>>> >>> however, I am still seeing
>>>> ConcurrentModificationExceptions
>>>> >>> while attempting to run more than 1 client in
>>>> Session
>>>> Direct
>>>> >>> mode (
>>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>>> >>> These exceptions are thrown throughout the
>>>> duration of the
>>>> >>> run. FYI - I deployed the same ear on Geronimo
>>>> 1.1.1 and
>>>> >>> didn't have a problem scaling up the users for
>>>> Session
>>>> >>> Direct mode.
>>>> >>>
>>>> >>> java.util.ConcurrentModificationException
>>>> >>> at
>>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connectio
>>>> nTrackingCoordinator.exit
>>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connectio
>>>> nTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
>>>> (<generated>)
>>>>
>>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>>> >>> (FastMethod.java :53)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>> (FastMethodInvoker.java:38)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>> (GBeanOperation.java:122)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>> >>> (GBeanInstance.java:820)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>>>> (RawInvoker.java:57)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>> (RawOperationInvoker.java:35)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>> >>> ( ProxyMethodInterceptor.java:96)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.connector.outbound.connectiontracking.Connectio
>>>> nTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>>> (SystemExceptionInterceptor.java:35)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke
>>>> (DefaultSubjectInterceptor.java
>>>> >>> :49)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
>>>> (DefaultStatelessEjbContainer.java:178)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$
>>>> $FastClassByCGLIB$$7ad7a562.invoke
>>>> (<generated>)
>>>> >>>
>>>> >>> at
>>>> >>> net.sf.cglib.reflect.FastMethod.invoke
>>>> (FastMethod.java:53)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>>> (FastMethodInvoker.java:38)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>>> >>> (GBeanOperation.java:122)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>>> (GBeanInstance.java:820)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
>>>> :57)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>>> >>> (RawOperationInvoker.java:35)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>>> (ProxyMethodInterceptor.java:96)
>>>> >>> at
>>>> >>> org.apache.openejb.StatelessEjbContainer$
>>>> $EnhancerByCGLIB$$5c554f35.invoke
>>>>
>>>> >>> (<generated>)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.AbstractEjbDeployment.invoke
>>>> (AbstractEjbDeployment.java:195)
>>>> >>> at
>>>> >>>
>>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept
>>>> (EJBMethodInterceptor.java:145)
>>>> >>> at
>>>> >>> org.apache.openejb.proxy.SessionEJBObject$
>>>> $EnhancerByCGLIB$$f5a9c1b2.login
>>>> >>> (<generated>)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.samples.daytrader.TradeAction.login
>>>> (TradeAction.java:449)
>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>> >>> web.TradeServletAction.doLogin
>>>> >>> <http://web.TradeServletAction.doLogin>
>>>> (TradeServletAction.java:364)
>>>> >>> at org.apache.geronimo.samples.daytrader .
>>>> >>> web.TradeAppServlet.performTask
>>>> >>> <http://web.TradeAppServlet.performTask>
>>>> (TradeAppServlet.java:126)
>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>> >>> web.TradeAppServlet.doPost
>>>> >>> <http://web.TradeAppServlet.doPost>
>>>> (TradeAppServlet.java :91)
>>>> >>> at javax.servlet.http.HttpServlet.service
>>>> >>> (HttpServlet.java:617)
>>>> >>> at
>>>> >>> javax.servlet.http.HttpServlet.service
>>>> (HttpServlet.java :690)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>> >>> (ApplicationFilterChain.java:252)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>> >>> (ApplicationFilterChain.java:173)
>>>> >>> at org.apache.geronimo.samples.daytrader.
>>>> >>> web.OrdersAlertFilter.doFilter
>>>> >>> <http://web.OrdersAlertFilter.doFilter>
>>>> (OrdersAlertFilter.java:91)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>> (ApplicationFilterChain.java
>>>> >>> :202)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>> >>> (ApplicationFilterChain.java :173)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.StandardWrapperValve.invoke
>>>> (StandardWrapperValve.java:213)
>>>> >>> at
>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>> >>> (StandardContextValve.java:178)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
>>>> (DefaultSubjectValve.java:56)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.tomcat.GeronimoStandardContext
>>>> $SystemMethodValve.invoke(GeronimoStandardContext.java
>>>> >>> :328)
>>>> >>> at
>>>> >>>
>>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>>> (GeronimoBeforeAfterValve.java:47)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.StandardHostValve.invoke
>>>> (StandardHostValve.java:126)
>>>> >>> at
>>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>>> >>> (ErrorReportValve.java:105)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.core.StandardEngineValve.invoke
>>>> (StandardEngineValve.java:107)
>>>> >>> at
>>>> >>>
>>>> org.apache.catalina.valves.AccessLogValve.invoke
>>>> (AccessLogValve.java:541)
>>>> >>> at
>>>> org.apache.catalina.connector.CoyoteAdapter.service
>>>> >>> (CoyoteAdapter.java :148)
>>>> >>> at
>>>> >>>
>>>> org.apache.coyote.http11.Http11Processor.process
>>>> (Http11Processor.java:869)
>>>> >>> at
>>>> >>> org.apache.coyote.http11.Http11BaseProtocol
>>>> $Http11ConnectionHandler.processConnection
>>>> (Http11BaseProtocol.java
>>>> >>> :667)
>>>> >>> at
>>>> >>>
>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
>>>> (PoolTcpEndpoint.java:527)
>>>> >>> at
>>>> >>>
>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
>>>> (LeaderFollowerWorkerThread.java:80)
>>>> >>> at
>>>> >>> org.apache.tomcat.util.threads.ThreadPool
>>>> $ControlRunnable.run
>>>> >>> (ThreadPool.java:684)
>>>> >>> at java.lang.Thread.run(Thread.java:797)
>>>> >>>
>>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>>> <ma...@planet57.com>
>>>> >>> <mailto:jason@planet57.com
>>>> <ma...@planet57.com>>> wrote:
>>>> >>>
>>>> >>> Aight, no worries. I still don't fully
>>>> understand
>>>> all
>>>> >>> that plugin stuff... yet ;-)
>>>> >>>
>>>> >>> --jason
>>>> >>>
>>>> >>>
>>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>>> >>>
>>>> >>>> The change I have cued up replaces "
>>>> 1.2-SNAPSHOT" with
>>>> >>>> " 1.2" for all the catalog entries. So it
>>>> would
>>>> break
>>>> >>>> anyone using the Geronimo plugin repo from a
>>>> >>>> 1.2-SNAPSHOT server (maybe not a huge
>>>> deal). Also,
>>>> >>>> I've tested the catalog updates by looping
>>>> http
>>>> >>>> requests to repo1.maven.org/maven2
>>>> <http://repo1.maven.org/maven2>
>>>> >>>> <http://repo1.maven.org/maven2> back to my
>>>> local
>>>> maven
>>>> >>>> repo. So I've made some assumptions about
>>>> the repo
>>>> >>>> layout that should probably be verified.
>>>> >>>>
>>>> >>>> Best wishes,
>>>> >>>> Paul
>>>> >>>>
>>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon
>>>> wrote:
>>>> >>>>
>>>> >>>>> Will it hurt anything to commit it now?
>>>> Or will it
>>>> >>>>> break things?
>>>> >>>>>
>>>> >>>>> --jason
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan
>>>> wrote:
>>>> >>>>>
>>>> >>>>>>
>>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>> >>>>>>
>>>> >>>>>>> I couldn't do much with the framework
>>>> assembly
>>>> as it
>>>> >>>>>>> requires a plugin repository with 1.2
>>>> plugins and
>>>> >>>>>>> AFAIK there is no such plugin repository
>>>> available
>>>> >>>>>>> yet. Will you be making the plugins
>>>> available for
>>>> >>>>>>> 1.2 as you make the release available? If
>>>> not, then
>>>> >>>>>>> perhaps we shouldn't include the framework
>>>> assembly
>>>> >>>>>>> in the distribution.
>>>> >>>>>>
>>>> >>>>>> I updated the plugin catalog stuff in
>>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2
>>>> locally
>>>> and ran
>>>> >>>>>> some quick tests of plugin download &
>>>> install from
>>>> >>>>>> maven repo. I'm ready to commit if/when
>>>> the 1.2
>>>> >>>>>> artifacts are published to central.
>>>> >>>>>>
>>>> >>>>>> Best wishes,
>>>> >>>>>> Paul
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> "I say never be complete, I say stop being
>>>> perfect, I say
>>>> >>> let... lets evolve, let the chips fall where
>>>> they may." -
>>>> >>> Tyler Durden
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> "I say never be complete, I say stop being perfect, I
>>>> say
>>>> let...
>>>> >> lets evolve, let the chips fall where they may." -
>>>> Tyler Durden
>>>> >> <geronimo.log>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > "I say never be complete, I say stop being perfect, I say
>>>> let...
>>>> lets
>>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>>
>>>>
>>>>
>>>>
>>>> --"I say never be complete, I say stop being perfect, I say
>>>> let... lets evolve, let the chips fall where they may." - Tyler
>>>> Durden
>>> Index: /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>> ConnectionTrackingCoordinator.java
>>> ===================================================================
>>> --- /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>> ConnectionTrackingCoordinator.java (revision 526213)
>>> +++ /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
>>> java/org/apache/geronimo/connector/outbound/connectiontracking/
>>> ConnectionTrackingCoordinator.java (working copy)
>>> @@ -124,7 +124,23 @@
>>>
>>> // if no connection remain clear context... we
>>> could support automatic commit, rollback or exception here
>>> if (connections.isEmpty()) {
>>> - i.remove();
>>> + boolean retry = false;
>>> + int numberOfRetries = 0;
>>> + do {
>>> + try {
>>> + i.remove();
>>> + } catch
>>> (java.util.ConcurrentModificationException ex) {
>>> + if (numberOfRetries < 5) {
>>> + retry = true;
>>> + } else {
>>> + retry = false;
>>> + }
>>> + numberOfRetries += 1;
>>> + }
>>> + } while (retry);
>>> + if (numberOfRetries >= 5) {
>>> + throw new ResourceException
>>> ("ConcurrentModificationException - Unable to remove resource");
>>> + }
>>> }
>>> }
>>> } finally {
>>
>>
>>
>>
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Whew!
Maybe now (I ran the openejb tests this time)
From what I understand, java.util.Stack is internally sychronized since
it is an extension of Vector which is synchronized.
So, here is a patch that replaces the LinkedList with a Stack.
It does pass the OpenEJB tests and will hopefully stand up under stress
with daytrader under load.
Sorry about the previous noise - I'm anxious to get G1.2 out so that
everyone can get back to G2 - Plus, this same issue will need to be
fixed in OpenEJB 3 if this corrects the problem.
Anyway, hopefully this will get 1.2 closer to the door,
Jay
David Jencks wrote:
> I don't think this is acceptable. There should be only one thread
> working with the context at a time. Either this exception is caused
> by modifying the collection in the same thread in which case we can
> fix it easily or it is caused by more than one thread having access to
> a context at once. Since by my reading of the code this is a context
> attached to a stateless session bean instance, that would mean that
> more than one thread is using a stateless session bean instance at
> once, which is definitely cause to -1 the release.
>
> I hope there's another possibility I haven't thought of..... but
> hiding the problem is not acceptable unless we really understand what
> is going on and are really convinced it's harmless.
>
> thanks
> david jencks
>
> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>
>> Chris (do you go by Chris or Christopher?),
>>
>> Here is a patch that I just wrote that allows the exit routine of
>> ConnectionTrackingCoordinator to finish cleanly after a number (5) of
>> attempts at removing the resource.
>>
>> If it fails after five tries, then the routine exits and throws a
>> ResourceException (that will hopefully be caught further up the stack).
>>
>> Would you like to try it to see if it solves your concurrency problem?
>>
>> Jay
>>
>> Christopher Blythe wrote:
>>> Doubtful... everything tested fine under light browser based
>>> testing. As the exception suggests, this is a concurrency problem
>>> that you would only hit under load.
>>>
>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>
>>> If Matt had no problem deploying and testing DT, could it be a Java
>>> version or classpath issue?
>>>
>>> That could explain the difference in the exception during
>>> deployment
>>> (and the problems during deployment could possibly explain the run
>>> time
>>> problems).
>>>
>>> Jay
>>>
>>> Christopher Blythe wrote:
>>> > I use a commercial load driving tool... FYI, I'm fairly
>>> certain that
>>> > G-2.0 has the same issue.
>>> >
>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>> <ma...@yahoo.com>
>>> > <mailto:david_jencks@yahoo.com <ma...@yahoo.com>>>
>>> wrote:
>>> >
>>> > I think we need to figure out why the
>>> > concurrentModificationException is happening before we
>>> release. I
>>> > think that one possible reason is that we are multithreading
>>> > stateless session bean instances. I hope this isn't the
>>> cause....
>>> > but IMO we need to find out.
>>> >
>>> > Chris, how do you run the several clients? manually or with
>>> a tool?
>>> >
>>> > thanks
>>> > david jencks
>>> >
>>> >
>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>> >
>>> >> Gave it a shot... no luck. As soon as I started 2
>>> clients, the
>>> >> same exceptions started to pile up. I have attached the
>>> >> geronimo.log. Also, noticed the following exception during
>>> startup.
>>> >>
>>> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
>>> >> connection from /127.0.0.1:28428: java.io.IOException: Wire
>>> >> format negociation timeout: peer did not send his wire
>>> format.
>>> >> java.io.IOException: Wire format negociation timeout:
>>> peer did
>>> >> not send his wire format.
>>> >> at
>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>> >> (WireFormatNegotiator.java :88)
>>> >> at
>>> >>
>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
>>>
>>> >> at
>>> org.apache.activemq.broker.TransportConnection.dispatch
>>> >> (TransportConnection.java :1138)
>>> >> at
>>> >>
>>> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
>>>
>>> >> at
>>> >> org.apache.activemq.broker.TransportConnection.start
>>> (TransportConnection.java
>>> >> :885)
>>> >> at
>>> org.apache.activemq.broker.TransportConnector$1.onAccept
>>> >> (TransportConnector.java:148)
>>> >> at
>>> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>> (TcpTransportServer.java:167)
>>> >> at java.lang.Thread.run (Thread.java:797)
>>> >>
>>> >>
>>> >>
>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>> <ma...@hogstrom.org>
>>> >> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>>
>>> wrote:
>>> >>
>>> >> Only a very light load from a few browsers. One thing
>>> to try
>>> >> is to increase the number of SLSBs in the pool.
>>> >>
>>> >> Can you add
>>> >>
>>> >> <session>
>>> >> <ejb-name>TradeJDBC</ejb-name>
>>> >> <jndi-name>ejb/TradeJDBC</jndi-name>
>>> >> <cache-size>100</cache-size>
>>> >> </session>
>>> >>
>>> >> to your plan and redeploy. I added some support for
>>> multiple
>>> >> SLSBs in a pool for 1.2 which we did not have
>>> before. This
>>> >> will hopefully make it better and not worse :)
>>> >>
>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>>> >>
>>> >>> Matt...
>>> >>>
>>> >>> You mentioned that you deployed DayTrader 1.2... did
>>> you
>>> >>> happen to run it under load? JDBC/Direct mode looks
>>> good;
>>> >>> however, I am still seeing
>>> ConcurrentModificationExceptions
>>> >>> while attempting to run more than 1 client in Session
>>> Direct
>>> >>> mode (
>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>> >>> These exceptions are thrown throughout the duration
>>> of the
>>> >>> run. FYI - I deployed the same ear on Geronimo 1.1.1
>>> and
>>> >>> didn't have a problem scaling up the users for Session
>>> >>> Direct mode.
>>> >>>
>>> >>> java.util.ConcurrentModificationException
>>> >>> at
>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
>>>
>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>>>
>>>
>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>> >>> (FastMethod.java :53)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>> (FastMethodInvoker.java:38)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>>>
>>> >>> at
>>> >>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>> >>> (GBeanInstance.java:820)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>>>
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>> >>> ( ProxyMethodInterceptor.java:96)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>> >>> at
>>> >>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>> (SystemExceptionInterceptor.java:35)
>>> >>> at
>>> >>>
>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java
>>>
>>> >>> :49)
>>> >>> at
>>> >>>
>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java:178)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
>>>
>>> (<generated>)
>>> >>>
>>> >>> at
>>> >>>
>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>> (FastMethodInvoker.java:38)
>>> >>> at
>>> >>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>> >>> (GBeanOperation.java:122)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
>>>
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
>>> :57)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>> >>> (RawOperationInvoker.java:35)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
>>>
>>>
>>> >>> (<generated>)
>>> >>> at
>>> >>>
>>> org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
>>>
>>> >>> (<generated>)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java:449)
>>>
>>> >>> at org.apache.geronimo.samples.daytrader.
>>> >>> web.TradeServletAction.doLogin
>>> >>>
>>> <http://web.TradeServletAction.doLogin>(TradeServletAction.java:364)
>>> >>> at org.apache.geronimo.samples.daytrader .
>>> >>> web.TradeAppServlet.performTask
>>> >>>
>>> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java:126)
>>> >>> at org.apache.geronimo.samples.daytrader.
>>> >>> web.TradeAppServlet.doPost
>>> >>>
>>> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java :91)
>>> >>> at javax.servlet.http.HttpServlet.service
>>> >>> (HttpServlet.java:617)
>>> >>> at
>>> >>>
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java :690)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>> >>> (ApplicationFilterChain.java:252)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>> >>> (ApplicationFilterChain.java:173)
>>> >>> at org.apache.geronimo.samples.daytrader.
>>> >>> web.OrdersAlertFilter.doFilter
>>> >>>
>>> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java:91)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>> (ApplicationFilterChain.java
>>> >>> :202)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>> >>> (ApplicationFilterChain.java :173)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>
>>> >>> at
>>> org.apache.catalina.core.StandardContextValve.invoke
>>> >>> (StandardContextValve.java:178)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>>>
>>> >>> at
>>> >>>
>>> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java
>>>
>>> >>> :328)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>> (GeronimoBeforeAfterValve.java:47)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>>>
>>> >>> at
>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>> >>> (ErrorReportValve.java:105)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>>>
>>> >>> at
>>> >>>
>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
>>>
>>> >>> at
>>> org.apache.catalina.connector.CoyoteAdapter.service
>>> >>> (CoyoteAdapter.java :148)
>>> >>> at
>>> >>>
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>>>
>>> >>> at
>>> >>>
>>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
>>>
>>> (Http11BaseProtocol.java
>>> >>> :667)
>>> >>> at
>>> >>>
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>>>
>>> >>> at
>>> >>>
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>
>>> >>> at
>>> >>>
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
>>> >>> (ThreadPool.java:684)
>>> >>> at java.lang.Thread.run(Thread.java:797)
>>> >>>
>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>> <ma...@planet57.com>
>>> >>> <mailto:jason@planet57.com
>>> <ma...@planet57.com>>> wrote:
>>> >>>
>>> >>> Aight, no worries. I still don't fully understand
>>> all
>>> >>> that plugin stuff... yet ;-)
>>> >>>
>>> >>> --jason
>>> >>>
>>> >>>
>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>> >>>
>>> >>>> The change I have cued up replaces "
>>> 1.2-SNAPSHOT" with
>>> >>>> " 1.2" for all the catalog entries. So it would
>>> break
>>> >>>> anyone using the Geronimo plugin repo from a
>>> >>>> 1.2-SNAPSHOT server (maybe not a huge deal).
>>> Also,
>>> >>>> I've tested the catalog updates by looping http
>>> >>>> requests to repo1.maven.org/maven2
>>> <http://repo1.maven.org/maven2>
>>> >>>> <http://repo1.maven.org/maven2> back to my local
>>> maven
>>> >>>> repo. So I've made some assumptions about the
>>> repo
>>> >>>> layout that should probably be verified.
>>> >>>>
>>> >>>> Best wishes,
>>> >>>> Paul
>>> >>>>
>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>> >>>>
>>> >>>>> Will it hurt anything to commit it now? Or
>>> will it
>>> >>>>> break things?
>>> >>>>>
>>> >>>>> --jason
>>> >>>>>
>>> >>>>>
>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>> >>>>>
>>> >>>>>>
>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>> >>>>>>
>>> >>>>>>> I couldn't do much with the framework assembly
>>> as it
>>> >>>>>>> requires a plugin repository with 1.2
>>> plugins and
>>> >>>>>>> AFAIK there is no such plugin repository
>>> available
>>> >>>>>>> yet. Will you be making the plugins
>>> available for
>>> >>>>>>> 1.2 as you make the release available? If
>>> not, then
>>> >>>>>>> perhaps we shouldn't include the framework
>>> assembly
>>> >>>>>>> in the distribution.
>>> >>>>>>
>>> >>>>>> I updated the plugin catalog stuff in
>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally
>>> and ran
>>> >>>>>> some quick tests of plugin download & install
>>> from
>>> >>>>>> maven repo. I'm ready to commit if/when the 1.2
>>> >>>>>> artifacts are published to central.
>>> >>>>>>
>>> >>>>>> Best wishes,
>>> >>>>>> Paul
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> "I say never be complete, I say stop being perfect,
>>> I say
>>> >>> let... lets evolve, let the chips fall where they
>>> may." -
>>> >>> Tyler Durden
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> "I say never be complete, I say stop being perfect, I say
>>> let...
>>> >> lets evolve, let the chips fall where they may." - Tyler
>>> Durden
>>> >> <geronimo.log>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > "I say never be complete, I say stop being perfect, I say let...
>>> lets
>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>
>>>
>>>
>>>
>>> --"I say never be complete, I say stop being perfect, I say let...
>>> lets evolve, let the chips fall where they may." - Tyler Durden
>> Index:
>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>
>> ===================================================================
>> ---
>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>> (revision 526213)
>> +++
>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>> (working copy)
>> @@ -124,7 +124,23 @@
>>
>> // if no connection remain clear context... we could
>> support automatic commit, rollback or exception here
>> if (connections.isEmpty()) {
>> - i.remove();
>> + boolean retry = false;
>> + int numberOfRetries = 0;
>> + do {
>> + try {
>> + i.remove();
>> + } catch
>> (java.util.ConcurrentModificationException ex) {
>> + if (numberOfRetries < 5) {
>> + retry = true;
>> + } else {
>> + retry = false;
>> + }
>> + numberOfRetries += 1;
>> + }
>> + } while (retry);
>> + if (numberOfRetries >= 5) {
>> + throw new
>> ResourceException("ConcurrentModificationException - Unable to remove
>> resource");
>> + }
>> }
>> }
>> } finally {
>
>
>
>
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Hello all,
New attempt that doesn't just hide the problem.
I managed to find reference on how to make a linked list behave as
synchronized (above and beyond simply trying to access them from within
synchronized code blocks).
Attached is the patch - It is actually for OpenEJB...I'm going to wait
until someone has a chance to confirm that it actually resolves the
Geronimo/Daytrader issue then make the JIRA over on OpenEJB.
Jay
David Jencks wrote:
> I don't think this is acceptable. There should be only one thread
> working with the context at a time. Either this exception is caused
> by modifying the collection in the same thread in which case we can
> fix it easily or it is caused by more than one thread having access to
> a context at once. Since by my reading of the code this is a context
> attached to a stateless session bean instance, that would mean that
> more than one thread is using a stateless session bean instance at
> once, which is definitely cause to -1 the release.
>
> I hope there's another possibility I haven't thought of..... but
> hiding the problem is not acceptable unless we really understand what
> is going on and are really convinced it's harmless.
>
> thanks
> david jencks
>
> On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
>
>> Chris (do you go by Chris or Christopher?),
>>
>> Here is a patch that I just wrote that allows the exit routine of
>> ConnectionTrackingCoordinator to finish cleanly after a number (5) of
>> attempts at removing the resource.
>>
>> If it fails after five tries, then the routine exits and throws a
>> ResourceException (that will hopefully be caught further up the stack).
>>
>> Would you like to try it to see if it solves your concurrency problem?
>>
>> Jay
>>
>> Christopher Blythe wrote:
>>> Doubtful... everything tested fine under light browser based
>>> testing. As the exception suggests, this is a concurrency problem
>>> that you would only hit under load.
>>>
>>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>>
>>> If Matt had no problem deploying and testing DT, could it be a Java
>>> version or classpath issue?
>>>
>>> That could explain the difference in the exception during
>>> deployment
>>> (and the problems during deployment could possibly explain the run
>>> time
>>> problems).
>>>
>>> Jay
>>>
>>> Christopher Blythe wrote:
>>> > I use a commercial load driving tool... FYI, I'm fairly
>>> certain that
>>> > G-2.0 has the same issue.
>>> >
>>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>>> <ma...@yahoo.com>
>>> > <mailto:david_jencks@yahoo.com <ma...@yahoo.com>>>
>>> wrote:
>>> >
>>> > I think we need to figure out why the
>>> > concurrentModificationException is happening before we
>>> release. I
>>> > think that one possible reason is that we are multithreading
>>> > stateless session bean instances. I hope this isn't the
>>> cause....
>>> > but IMO we need to find out.
>>> >
>>> > Chris, how do you run the several clients? manually or with
>>> a tool?
>>> >
>>> > thanks
>>> > david jencks
>>> >
>>> >
>>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>>> >
>>> >> Gave it a shot... no luck. As soon as I started 2
>>> clients, the
>>> >> same exceptions started to pile up. I have attached the
>>> >> geronimo.log. Also, noticed the following exception during
>>> startup.
>>> >>
>>> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
>>> >> connection from /127.0.0.1:28428: java.io.IOException: Wire
>>> >> format negociation timeout: peer did not send his wire
>>> format.
>>> >> java.io.IOException: Wire format negociation timeout:
>>> peer did
>>> >> not send his wire format.
>>> >> at
>>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>>> >> (WireFormatNegotiator.java :88)
>>> >> at
>>> >>
>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
>>>
>>> >> at
>>> org.apache.activemq.broker.TransportConnection.dispatch
>>> >> (TransportConnection.java :1138)
>>> >> at
>>> >>
>>> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
>>>
>>> >> at
>>> >> org.apache.activemq.broker.TransportConnection.start
>>> (TransportConnection.java
>>> >> :885)
>>> >> at
>>> org.apache.activemq.broker.TransportConnector$1.onAccept
>>> >> (TransportConnector.java:148)
>>> >> at
>>> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
>>> (TcpTransportServer.java:167)
>>> >> at java.lang.Thread.run (Thread.java:797)
>>> >>
>>> >>
>>> >>
>>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>>> <ma...@hogstrom.org>
>>> >> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>>
>>> wrote:
>>> >>
>>> >> Only a very light load from a few browsers. One thing
>>> to try
>>> >> is to increase the number of SLSBs in the pool.
>>> >>
>>> >> Can you add
>>> >>
>>> >> <session>
>>> >> <ejb-name>TradeJDBC</ejb-name>
>>> >> <jndi-name>ejb/TradeJDBC</jndi-name>
>>> >> <cache-size>100</cache-size>
>>> >> </session>
>>> >>
>>> >> to your plan and redeploy. I added some support for
>>> multiple
>>> >> SLSBs in a pool for 1.2 which we did not have
>>> before. This
>>> >> will hopefully make it better and not worse :)
>>> >>
>>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>>> >>
>>> >>> Matt...
>>> >>>
>>> >>> You mentioned that you deployed DayTrader 1.2... did
>>> you
>>> >>> happen to run it under load? JDBC/Direct mode looks
>>> good;
>>> >>> however, I am still seeing
>>> ConcurrentModificationExceptions
>>> >>> while attempting to run more than 1 client in Session
>>> Direct
>>> >>> mode (
>>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>>> >>> These exceptions are thrown throughout the duration
>>> of the
>>> >>> run. FYI - I deployed the same ear on Geronimo 1.1.1
>>> and
>>> >>> didn't have a problem scaling up the users for Session
>>> >>> Direct mode.
>>> >>>
>>> >>> java.util.ConcurrentModificationException
>>> >>> at
>>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
>>>
>>> >>> ( ConnectionTrackingCoordinator.java :127)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>>>
>>>
>>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>>> >>> (FastMethod.java :53)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>> (FastMethodInvoker.java:38)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>>>
>>> >>> at
>>> >>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>> >>> (GBeanInstance.java:820)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>>>
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>> >>> ( ProxyMethodInterceptor.java:96)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>> >>> (NoConnectionEnlistingInterceptor.java:70)
>>> >>> at
>>> >>> org.apache.openejb.SystemExceptionInterceptor.invoke
>>> (SystemExceptionInterceptor.java:35)
>>> >>> at
>>> >>>
>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java
>>>
>>> >>> :49)
>>> >>> at
>>> >>>
>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java:178)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
>>>
>>> (<generated>)
>>> >>>
>>> >>> at
>>> >>>
>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>> (FastMethodInvoker.java:38)
>>> >>> at
>>> >>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>> >>> (GBeanOperation.java:122)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
>>>
>>> >>> at
>>> >>>
>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
>>> :57)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>> >>> (RawOperationInvoker.java:35)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
>>>
>>>
>>> >>> (<generated>)
>>> >>> at
>>> >>>
>>> org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
>>>
>>> >>> at
>>> >>>
>>> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
>>>
>>> >>> (<generated>)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java:449)
>>>
>>> >>> at org.apache.geronimo.samples.daytrader.
>>> >>> web.TradeServletAction.doLogin
>>> >>>
>>> <http://web.TradeServletAction.doLogin>(TradeServletAction.java:364)
>>> >>> at org.apache.geronimo.samples.daytrader .
>>> >>> web.TradeAppServlet.performTask
>>> >>>
>>> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java:126)
>>> >>> at org.apache.geronimo.samples.daytrader.
>>> >>> web.TradeAppServlet.doPost
>>> >>>
>>> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java :91)
>>> >>> at javax.servlet.http.HttpServlet.service
>>> >>> (HttpServlet.java:617)
>>> >>> at
>>> >>>
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java :690)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>> >>> (ApplicationFilterChain.java:252)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>> >>> (ApplicationFilterChain.java:173)
>>> >>> at org.apache.geronimo.samples.daytrader.
>>> >>> web.OrdersAlertFilter.doFilter
>>> >>>
>>> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java:91)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>> (ApplicationFilterChain.java
>>> >>> :202)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>> >>> (ApplicationFilterChain.java :173)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>
>>> >>> at
>>> org.apache.catalina.core.StandardContextValve.invoke
>>> >>> (StandardContextValve.java:178)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>>>
>>> >>> at
>>> >>>
>>> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java
>>>
>>> >>> :328)
>>> >>> at
>>> >>>
>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>>> (GeronimoBeforeAfterValve.java:47)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>>>
>>> >>> at
>>> org.apache.catalina.valves.ErrorReportValve.invoke
>>> >>> (ErrorReportValve.java:105)
>>> >>> at
>>> >>>
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>>>
>>> >>> at
>>> >>>
>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
>>>
>>> >>> at
>>> org.apache.catalina.connector.CoyoteAdapter.service
>>> >>> (CoyoteAdapter.java :148)
>>> >>> at
>>> >>>
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>>>
>>> >>> at
>>> >>>
>>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
>>>
>>> (Http11BaseProtocol.java
>>> >>> :667)
>>> >>> at
>>> >>>
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>>>
>>> >>> at
>>> >>>
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>
>>> >>> at
>>> >>>
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
>>> >>> (ThreadPool.java:684)
>>> >>> at java.lang.Thread.run(Thread.java:797)
>>> >>>
>>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>> <ma...@planet57.com>
>>> >>> <mailto:jason@planet57.com
>>> <ma...@planet57.com>>> wrote:
>>> >>>
>>> >>> Aight, no worries. I still don't fully understand
>>> all
>>> >>> that plugin stuff... yet ;-)
>>> >>>
>>> >>> --jason
>>> >>>
>>> >>>
>>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>> >>>
>>> >>>> The change I have cued up replaces "
>>> 1.2-SNAPSHOT" with
>>> >>>> " 1.2" for all the catalog entries. So it would
>>> break
>>> >>>> anyone using the Geronimo plugin repo from a
>>> >>>> 1.2-SNAPSHOT server (maybe not a huge deal).
>>> Also,
>>> >>>> I've tested the catalog updates by looping http
>>> >>>> requests to repo1.maven.org/maven2
>>> <http://repo1.maven.org/maven2>
>>> >>>> <http://repo1.maven.org/maven2> back to my local
>>> maven
>>> >>>> repo. So I've made some assumptions about the
>>> repo
>>> >>>> layout that should probably be verified.
>>> >>>>
>>> >>>> Best wishes,
>>> >>>> Paul
>>> >>>>
>>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>> >>>>
>>> >>>>> Will it hurt anything to commit it now? Or
>>> will it
>>> >>>>> break things?
>>> >>>>>
>>> >>>>> --jason
>>> >>>>>
>>> >>>>>
>>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>> >>>>>
>>> >>>>>>
>>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>> >>>>>>
>>> >>>>>>> I couldn't do much with the framework assembly
>>> as it
>>> >>>>>>> requires a plugin repository with 1.2
>>> plugins and
>>> >>>>>>> AFAIK there is no such plugin repository
>>> available
>>> >>>>>>> yet. Will you be making the plugins
>>> available for
>>> >>>>>>> 1.2 as you make the release available? If
>>> not, then
>>> >>>>>>> perhaps we shouldn't include the framework
>>> assembly
>>> >>>>>>> in the distribution.
>>> >>>>>>
>>> >>>>>> I updated the plugin catalog stuff in
>>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally
>>> and ran
>>> >>>>>> some quick tests of plugin download & install
>>> from
>>> >>>>>> maven repo. I'm ready to commit if/when the 1.2
>>> >>>>>> artifacts are published to central.
>>> >>>>>>
>>> >>>>>> Best wishes,
>>> >>>>>> Paul
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> "I say never be complete, I say stop being perfect,
>>> I say
>>> >>> let... lets evolve, let the chips fall where they
>>> may." -
>>> >>> Tyler Durden
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> "I say never be complete, I say stop being perfect, I say
>>> let...
>>> >> lets evolve, let the chips fall where they may." - Tyler
>>> Durden
>>> >> <geronimo.log>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > "I say never be complete, I say stop being perfect, I say let...
>>> lets
>>> > evolve, let the chips fall where they may." - Tyler Durden
>>>
>>>
>>>
>>>
>>> --"I say never be complete, I say stop being perfect, I say let...
>>> lets evolve, let the chips fall where they may." - Tyler Durden
>> Index:
>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>>
>> ===================================================================
>> ---
>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>> (revision 526213)
>> +++
>> /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinator.java
>> (working copy)
>> @@ -124,7 +124,23 @@
>>
>> // if no connection remain clear context... we could
>> support automatic commit, rollback or exception here
>> if (connections.isEmpty()) {
>> - i.remove();
>> + boolean retry = false;
>> + int numberOfRetries = 0;
>> + do {
>> + try {
>> + i.remove();
>> + } catch
>> (java.util.ConcurrentModificationException ex) {
>> + if (numberOfRetries < 5) {
>> + retry = true;
>> + } else {
>> + retry = false;
>> + }
>> + numberOfRetries += 1;
>> + }
>> + } while (retry);
>> + if (numberOfRetries >= 5) {
>> + throw new
>> ResourceException("ConcurrentModificationException - Unable to remove
>> resource");
>> + }
>> }
>> }
>> } finally {
>
>
>
>
Re: [discuss] Release Geronimo 1.2
Posted by David Jencks <da...@yahoo.com>.
I don't think this is acceptable. There should be only one thread
working with the context at a time. Either this exception is caused
by modifying the collection in the same thread in which case we can
fix it easily or it is caused by more than one thread having access
to a context at once. Since by my reading of the code this is a
context attached to a stateless session bean instance, that would
mean that more than one thread is using a stateless session bean
instance at once, which is definitely cause to -1 the release.
I hope there's another possibility I haven't thought of..... but
hiding the problem is not acceptable unless we really understand what
is going on and are really convinced it's harmless.
thanks
david jencks
On Apr 6, 2007, at 1:40 PM, Jay D. McHugh wrote:
> Chris (do you go by Chris or Christopher?),
>
> Here is a patch that I just wrote that allows the exit routine of
> ConnectionTrackingCoordinator to finish cleanly after a number (5)
> of attempts at removing the resource.
>
> If it fails after five tries, then the routine exits and throws a
> ResourceException (that will hopefully be caught further up the
> stack).
>
> Would you like to try it to see if it solves your concurrency problem?
>
> Jay
>
> Christopher Blythe wrote:
>> Doubtful... everything tested fine under light browser based
>> testing. As the exception suggests, this is a concurrency problem
>> that you would only hit under load.
>>
>> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
>> <ma...@joyfulnoisewebdesign.com>> wrote:
>>
>> If Matt had no problem deploying and testing DT, could it be a
>> Java
>> version or classpath issue?
>>
>> That could explain the difference in the exception during
>> deployment
>> (and the problems during deployment could possibly explain the
>> run
>> time
>> problems).
>>
>> Jay
>>
>> Christopher Blythe wrote:
>> > I use a commercial load driving tool... FYI, I'm fairly
>> certain that
>> > G-2.0 has the same issue.
>> >
>> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
>> <ma...@yahoo.com>
>> > <mailto:david_jencks@yahoo.com
>> <ma...@yahoo.com>>>
>> wrote:
>> >
>> > I think we need to figure out why the
>> > concurrentModificationException is happening before we
>> release. I
>> > think that one possible reason is that we are
>> multithreading
>> > stateless session bean instances. I hope this isn't the
>> cause....
>> > but IMO we need to find out.
>> >
>> > Chris, how do you run the several clients? manually or
>> with
>> a tool?
>> >
>> > thanks
>> > david jencks
>> >
>> >
>> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>> >
>> >> Gave it a shot... no luck. As soon as I started 2
>> clients, the
>> >> same exceptions started to pile up. I have attached the
>> >> geronimo.log. Also, noticed the following exception during
>> startup.
>> >>
>> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
>> >> connection from /127.0.0.1:28428: java.io.IOException:
>> Wire
>> >> format negociation timeout: peer did not send his wire
>> format.
>> >> java.io.IOException: Wire format negociation timeout:
>> peer did
>> >> not send his wire format.
>> >> at
>> org.apache.activemq.transport.WireFormatNegotiator.oneway
>> >> (WireFormatNegotiator.java :88)
>> >> at
>> >> org.apache.activemq.transport.MutexTransport.oneway
>> (MutexTransport.java:47)
>> >> at
>> org.apache.activemq.broker.TransportConnection.dispatch
>> >> (TransportConnection.java :1138)
>> >> at
>> >>
>> org.apache.activemq.broker.TransportConnection.processDispatch
>> (TransportConnection.java:805)
>> >> at
>> >> org.apache.activemq.broker.TransportConnection.start
>> (TransportConnection.java
>> >> :885)
>> >> at org.apache.activemq.broker.TransportConnector
>> $1.onAccept
>> >> (TransportConnector.java:148)
>> >> at
>> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
>> (TcpTransportServer.java:167)
>> >> at java.lang.Thread.run (Thread.java:797)
>> >>
>> >>
>> >>
>> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>> <ma...@hogstrom.org>
>> >> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>>
>> wrote:
>> >>
>> >> Only a very light load from a few browsers. One thing
>> to try
>> >> is to increase the number of SLSBs in the pool.
>> >>
>> >> Can you add
>> >>
>> >> <session>
>> >> <ejb-name>TradeJDBC</ejb-name>
>> >> <jndi-name>ejb/TradeJDBC</jndi-
>> name>
>> >> <cache-size>100</cache-size>
>> >> </session>
>> >>
>> >> to your plan and redeploy. I added some support for
>> multiple
>> >> SLSBs in a pool for 1.2 which we did not have
>> before. This
>> >> will hopefully make it better and not worse :)
>> >>
>> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>> >>
>> >>> Matt...
>> >>>
>> >>> You mentioned that you deployed DayTrader 1.2...
>> did you
>> >>> happen to run it under load? JDBC/Direct mode
>> looks good;
>> >>> however, I am still seeing
>> ConcurrentModificationExceptions
>> >>> while attempting to run more than 1 client in Session
>> Direct
>> >>> mode (
>> https://issues.apache.org/jira/browse/GERONIMO-2708).
>> >>> These exceptions are thrown throughout the
>> duration of the
>> >>> run. FYI - I deployed the same ear on Geronimo
>> 1.1.1 and
>> >>> didn't have a problem scaling up the users for
>> Session
>> >>> Direct mode.
>> >>>
>> >>> java.util.ConcurrentModificationException
>> >>> at
>> java.util.HashMap$HashIterator.remove(HashMap.java:861)
>> >>> at
>> >>>
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> rackingCoordinator.exit
>> >>> ( ConnectionTrackingCoordinator.java :127)
>> >>> at
>> >>>
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>>
>> >>> at net.sf.cglib.reflect.FastMethod.invoke
>> >>> (FastMethod.java :53)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>> (FastMethodInvoker.java:38)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>> (GBeanOperation.java:122)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>> >>> (GBeanInstance.java:820)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>> (RawInvoker.java:57)
>> >>> at
>> >>>
>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>> (RawOperationInvoker.java:35)
>> >>> at
>> >>>
>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>> >>> ( ProxyMethodInterceptor.java:96)
>> >>> at
>> >>>
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> racker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>> >>> at
>> >>>
>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>> >>> (NoConnectionEnlistingInterceptor.java:70)
>> >>> at
>> >>> org.apache.openejb.SystemExceptionInterceptor.invoke
>> (SystemExceptionInterceptor.java:35)
>> >>> at
>> >>>
>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke
>> (DefaultSubjectInterceptor.java
>> >>> :49)
>> >>> at
>> >>>
>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
>> (DefaultStatelessEjbContainer.java:178)
>> >>> at
>> >>>
>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$
>> $FastClassByCGLIB$$7ad7a562.invoke
>> (<generated>)
>> >>>
>> >>> at
>> >>> net.sf.cglib.reflect.FastMethod.invoke
>> (FastMethod.java:53)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>> (FastMethodInvoker.java:38)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>> >>> (GBeanOperation.java:122)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>> (GBeanInstance.java:820)
>> >>> at
>> >>>
>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
>> :57)
>> >>> at
>> >>>
>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>> >>> (RawOperationInvoker.java:35)
>> >>> at
>> >>>
>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>> (ProxyMethodInterceptor.java:96)
>> >>> at
>> >>> org.apache.openejb.StatelessEjbContainer$
>> $EnhancerByCGLIB$$5c554f35.invoke
>>
>> >>> (<generated>)
>> >>> at
>> >>> org.apache.openejb.AbstractEjbDeployment.invoke
>> (AbstractEjbDeployment.java:195)
>> >>> at
>> >>>
>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept
>> (EJBMethodInterceptor.java:145)
>> >>> at
>> >>> org.apache.openejb.proxy.SessionEJBObject$
>> $EnhancerByCGLIB$$f5a9c1b2.login
>> >>> (<generated>)
>> >>> at
>> >>>
>> org.apache.geronimo.samples.daytrader.TradeAction.login
>> (TradeAction.java:449)
>> >>> at org.apache.geronimo.samples.daytrader.
>> >>> web.TradeServletAction.doLogin
>> >>> <http://web.TradeServletAction.doLogin>
>> (TradeServletAction.java:364)
>> >>> at org.apache.geronimo.samples.daytrader .
>> >>> web.TradeAppServlet.performTask
>> >>> <http://web.TradeAppServlet.performTask>
>> (TradeAppServlet.java:126)
>> >>> at org.apache.geronimo.samples.daytrader.
>> >>> web.TradeAppServlet.doPost
>> >>> <http://web.TradeAppServlet.doPost>
>> (TradeAppServlet.java :91)
>> >>> at javax.servlet.http.HttpServlet.service
>> >>> (HttpServlet.java:617)
>> >>> at
>> >>> javax.servlet.http.HttpServlet.service
>> (HttpServlet.java :690)
>> >>> at
>> >>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> >>> (ApplicationFilterChain.java:252)
>> >>> at
>> >>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>> >>> (ApplicationFilterChain.java:173)
>> >>> at org.apache.geronimo.samples.daytrader.
>> >>> web.OrdersAlertFilter.doFilter
>> >>> <http://web.OrdersAlertFilter.doFilter>
>> (OrdersAlertFilter.java:91)
>> >>> at
>> >>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java
>> >>> :202)
>> >>> at
>> >>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>> >>> (ApplicationFilterChain.java :173)
>> >>> at
>> >>>
>> org.apache.catalina.core.StandardWrapperValve.invoke
>> (StandardWrapperValve.java:213)
>> >>> at
>> org.apache.catalina.core.StandardContextValve.invoke
>> >>> (StandardContextValve.java:178)
>> >>> at
>> >>>
>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
>> (DefaultSubjectValve.java:56)
>> >>> at
>> >>>
>> org.apache.geronimo.tomcat.GeronimoStandardContext
>> $SystemMethodValve.invoke(GeronimoStandardContext.java
>> >>> :328)
>> >>> at
>> >>>
>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>> (GeronimoBeforeAfterValve.java:47)
>> >>> at
>> >>>
>> org.apache.catalina.core.StandardHostValve.invoke
>> (StandardHostValve.java:126)
>> >>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke
>> >>> (ErrorReportValve.java:105)
>> >>> at
>> >>>
>> org.apache.catalina.core.StandardEngineValve.invoke
>> (StandardEngineValve.java:107)
>> >>> at
>> >>> org.apache.catalina.valves.AccessLogValve.invoke
>> (AccessLogValve.java:541)
>> >>> at
>> org.apache.catalina.connector.CoyoteAdapter.service
>> >>> (CoyoteAdapter.java :148)
>> >>> at
>> >>> org.apache.coyote.http11.Http11Processor.process
>> (Http11Processor.java:869)
>> >>> at
>> >>> org.apache.coyote.http11.Http11BaseProtocol
>> $Http11ConnectionHandler.processConnection
>> (Http11BaseProtocol.java
>> >>> :667)
>> >>> at
>> >>>
>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
>> (PoolTcpEndpoint.java:527)
>> >>> at
>> >>>
>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
>> (LeaderFollowerWorkerThread.java:80)
>> >>> at
>> >>> org.apache.tomcat.util.threads.ThreadPool
>> $ControlRunnable.run
>> >>> (ThreadPool.java:684)
>> >>> at java.lang.Thread.run(Thread.java:797)
>> >>>
>> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>> <ma...@planet57.com>
>> >>> <mailto:jason@planet57.com
>> <ma...@planet57.com>>> wrote:
>> >>>
>> >>> Aight, no worries. I still don't fully
>> understand
>> all
>> >>> that plugin stuff... yet ;-)
>> >>>
>> >>> --jason
>> >>>
>> >>>
>> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>> >>>
>> >>>> The change I have cued up replaces "
>> 1.2-SNAPSHOT" with
>> >>>> " 1.2" for all the catalog entries. So it would
>> break
>> >>>> anyone using the Geronimo plugin repo from a
>> >>>> 1.2-SNAPSHOT server (maybe not a huge deal).
>> Also,
>> >>>> I've tested the catalog updates by looping http
>> >>>> requests to repo1.maven.org/maven2
>> <http://repo1.maven.org/maven2>
>> >>>> <http://repo1.maven.org/maven2> back to my local
>> maven
>> >>>> repo. So I've made some assumptions about
>> the repo
>> >>>> layout that should probably be verified.
>> >>>>
>> >>>> Best wishes,
>> >>>> Paul
>> >>>>
>> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>> >>>>
>> >>>>> Will it hurt anything to commit it now? Or
>> will it
>> >>>>> break things?
>> >>>>>
>> >>>>> --jason
>> >>>>>
>> >>>>>
>> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>> >>>>>
>> >>>>>>
>> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>> >>>>>>
>> >>>>>>> I couldn't do much with the framework
>> assembly
>> as it
>> >>>>>>> requires a plugin repository with 1.2
>> plugins and
>> >>>>>>> AFAIK there is no such plugin repository
>> available
>> >>>>>>> yet. Will you be making the plugins
>> available for
>> >>>>>>> 1.2 as you make the release available? If
>> not, then
>> >>>>>>> perhaps we shouldn't include the framework
>> assembly
>> >>>>>>> in the distribution.
>> >>>>>>
>> >>>>>> I updated the plugin catalog stuff in
>> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally
>> and ran
>> >>>>>> some quick tests of plugin download &
>> install from
>> >>>>>> maven repo. I'm ready to commit if/when
>> the 1.2
>> >>>>>> artifacts are published to central.
>> >>>>>>
>> >>>>>> Best wishes,
>> >>>>>> Paul
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> "I say never be complete, I say stop being
>> perfect, I say
>> >>> let... lets evolve, let the chips fall where they
>> may." -
>> >>> Tyler Durden
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> "I say never be complete, I say stop being perfect, I say
>> let...
>> >> lets evolve, let the chips fall where they may." -
>> Tyler Durden
>> >> <geronimo.log>
>> >
>> >
>> >
>> >
>> > --
>> > "I say never be complete, I say stop being perfect, I say
>> let...
>> lets
>> > evolve, let the chips fall where they may." - Tyler Durden
>>
>>
>>
>>
>> --
>> "I say never be complete, I say stop being perfect, I say let...
>> lets evolve, let the chips fall where they may." - Tyler Durden
> Index: /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/
> java/org/apache/geronimo/connector/outbound/connectiontracking/
> ConnectionTrackingCoordinator.java
> ===================================================================
> --- /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/
> org/apache/geronimo/connector/outbound/connectiontracking/
> ConnectionTrackingCoordinator.java (revision 526213)
> +++ /usr/src/geronimo-1.2/modules/geronimo-connector/src/main/java/
> org/apache/geronimo/connector/outbound/connectiontracking/
> ConnectionTrackingCoordinator.java (working copy)
> @@ -124,7 +124,23 @@
>
> // if no connection remain clear context... we
> could support automatic commit, rollback or exception here
> if (connections.isEmpty()) {
> - i.remove();
> + boolean retry = false;
> + int numberOfRetries = 0;
> + do {
> + try {
> + i.remove();
> + } catch
> (java.util.ConcurrentModificationException ex) {
> + if (numberOfRetries < 5) {
> + retry = true;
> + } else {
> + retry = false;
> + }
> + numberOfRetries += 1;
> + }
> + } while (retry);
> + if (numberOfRetries >= 5) {
> + throw new ResourceException
> ("ConcurrentModificationException - Unable to remove resource");
> + }
> }
> }
> } finally {
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Chris (do you go by Chris or Christopher?),
Here is a patch that I just wrote that allows the exit routine of
ConnectionTrackingCoordinator to finish cleanly after a number (5) of
attempts at removing the resource.
If it fails after five tries, then the routine exits and throws a
ResourceException (that will hopefully be caught further up the stack).
Would you like to try it to see if it solves your concurrency problem?
Jay
Christopher Blythe wrote:
> Doubtful... everything tested fine under light browser based testing.
> As the exception suggests, this is a concurrency problem that you
> would only hit under load.
>
> On 4/6/07, * Jay D. McHugh* <jay@joyfulnoisewebdesign.com
> <ma...@joyfulnoisewebdesign.com>> wrote:
>
> If Matt had no problem deploying and testing DT, could it be a Java
> version or classpath issue?
>
> That could explain the difference in the exception during deployment
> (and the problems during deployment could possibly explain the run
> time
> problems).
>
> Jay
>
> Christopher Blythe wrote:
> > I use a commercial load driving tool... FYI, I'm fairly certain that
> > G-2.0 has the same issue.
> >
> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
> <ma...@yahoo.com>
> > <mailto:david_jencks@yahoo.com <ma...@yahoo.com>>>
> wrote:
> >
> > I think we need to figure out why the
> > concurrentModificationException is happening before we
> release. I
> > think that one possible reason is that we are multithreading
> > stateless session bean instances. I hope this isn't the
> cause....
> > but IMO we need to find out.
> >
> > Chris, how do you run the several clients? manually or with
> a tool?
> >
> > thanks
> > david jencks
> >
> >
> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
> >
> >> Gave it a shot... no luck. As soon as I started 2 clients, the
> >> same exceptions started to pile up. I have attached the
> >> geronimo.log. Also, noticed the following exception during
> startup.
> >>
> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
> >> connection from /127.0.0.1:28428: java.io.IOException: Wire
> >> format negociation timeout: peer did not send his wire format.
> >> java.io.IOException: Wire format negociation timeout: peer did
> >> not send his wire format.
> >> at
> org.apache.activemq.transport.WireFormatNegotiator.oneway
> >> (WireFormatNegotiator.java :88)
> >> at
> >>
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
> >> at org.apache.activemq.broker.TransportConnection.dispatch
> >> (TransportConnection.java :1138)
> >> at
> >>
> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
> >> at
> >> org.apache.activemq.broker.TransportConnection.start
> (TransportConnection.java
> >> :885)
> >> at org.apache.activemq.broker.TransportConnector$1.onAccept
> >> (TransportConnector.java:148)
> >> at
> >> org.apache.activemq.transport.tcp.TcpTransportServer.run
> (TcpTransportServer.java:167)
> >> at java.lang.Thread.run (Thread.java:797)
> >>
> >>
> >>
> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
> <ma...@hogstrom.org>
> >> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>> wrote:
> >>
> >> Only a very light load from a few browsers. One thing
> to try
> >> is to increase the number of SLSBs in the pool.
> >>
> >> Can you add
> >>
> >> <session>
> >> <ejb-name>TradeJDBC</ejb-name>
> >> <jndi-name>ejb/TradeJDBC</jndi-name>
> >> <cache-size>100</cache-size>
> >> </session>
> >>
> >> to your plan and redeploy. I added some support for
> multiple
> >> SLSBs in a pool for 1.2 which we did not have before. This
> >> will hopefully make it better and not worse :)
> >>
> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
> >>
> >>> Matt...
> >>>
> >>> You mentioned that you deployed DayTrader 1.2... did you
> >>> happen to run it under load? JDBC/Direct mode looks good;
> >>> however, I am still seeing
> ConcurrentModificationExceptions
> >>> while attempting to run more than 1 client in Session
> Direct
> >>> mode (
> https://issues.apache.org/jira/browse/GERONIMO-2708).
> >>> These exceptions are thrown throughout the duration of the
> >>> run. FYI - I deployed the same ear on Geronimo 1.1.1 and
> >>> didn't have a problem scaling up the users for Session
> >>> Direct mode.
> >>>
> >>> java.util.ConcurrentModificationException
> >>> at
> java.util.HashMap$HashIterator.remove(HashMap.java:861)
> >>> at
> >>>
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
> >>> ( ConnectionTrackingCoordinator.java :127)
> >>> at
> >>>
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>
> >>> at net.sf.cglib.reflect.FastMethod.invoke
> >>> (FastMethod.java :53)
> >>> at
> >>>
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> >>> at
> >>>
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> >>> (GBeanInstance.java:820)
> >>> at
> >>>
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> >>> at
> >>>
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> >>> at
> >>>
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> >>> ( ProxyMethodInterceptor.java:96)
> >>> at
> >>>
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
> >>> at
> >>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
> >>> (NoConnectionEnlistingInterceptor.java:70)
> >>> at
> >>> org.apache.openejb.SystemExceptionInterceptor.invoke
> (SystemExceptionInterceptor.java:35)
> >>> at
> >>>
> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java
> >>> :49)
> >>> at
> >>>
> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java:178)
> >>> at
> >>>
> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
> (<generated>)
> >>>
> >>> at
> >>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> >>> at
> >>>
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> >>> (GBeanOperation.java:122)
> >>> at
> >>>
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> >>> at
> >>>
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
> :57)
> >>> at
> >>>
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> >>> (RawOperationInvoker.java:35)
> >>> at
> >>>
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> >>> at
> >>>
> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
>
> >>> (<generated>)
> >>> at
> >>>
> org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
> >>> at
> >>>
> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
> >>> at
> >>>
> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
> >>> (<generated>)
> >>> at
> >>>
> org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java:449)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.TradeServletAction.doLogin
> >>>
> <http://web.TradeServletAction.doLogin>(TradeServletAction.java:364)
> >>> at org.apache.geronimo.samples.daytrader .
> >>> web.TradeAppServlet.performTask
> >>>
> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java:126)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.TradeAppServlet.doPost
> >>>
> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java :91)
> >>> at javax.servlet.http.HttpServlet.service
> >>> (HttpServlet.java:617)
> >>> at
> >>>
> javax.servlet.http.HttpServlet.service(HttpServlet.java :690)
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> >>> (ApplicationFilterChain.java:252)
> >>> at
> >>> org.apache.catalina.core.ApplicationFilterChain.doFilter
> >>> (ApplicationFilterChain.java:173)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.OrdersAlertFilter.doFilter
> >>>
> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java:91)
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java
> >>> :202)
> >>> at
> >>> org.apache.catalina.core.ApplicationFilterChain.doFilter
> >>> (ApplicationFilterChain.java :173)
> >>> at
> >>>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> >>> at
> org.apache.catalina.core.StandardContextValve.invoke
> >>> (StandardContextValve.java:178)
> >>> at
> >>>
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> >>> at
> >>>
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java
> >>> :328)
> >>> at
> >>>
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
> (GeronimoBeforeAfterValve.java:47)
> >>> at
> >>>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> >>> at org.apache.catalina.valves.ErrorReportValve.invoke
> >>> (ErrorReportValve.java:105)
> >>> at
> >>>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> >>> at
> >>>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
> >>> at org.apache.catalina.connector.CoyoteAdapter.service
> >>> (CoyoteAdapter.java :148)
> >>> at
> >>>
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> >>> at
> >>>
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
> (Http11BaseProtocol.java
> >>> :667)
> >>> at
> >>>
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> >>> at
> >>>
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> >>> at
> >>>
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
> >>> (ThreadPool.java:684)
> >>> at java.lang.Thread.run(Thread.java:797)
> >>>
> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
> <ma...@planet57.com>
> >>> <mailto:jason@planet57.com
> <ma...@planet57.com>>> wrote:
> >>>
> >>> Aight, no worries. I still don't fully understand
> all
> >>> that plugin stuff... yet ;-)
> >>>
> >>> --jason
> >>>
> >>>
> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
> >>>
> >>>> The change I have cued up replaces "
> 1.2-SNAPSHOT" with
> >>>> " 1.2" for all the catalog entries. So it would
> break
> >>>> anyone using the Geronimo plugin repo from a
> >>>> 1.2-SNAPSHOT server (maybe not a huge deal). Also,
> >>>> I've tested the catalog updates by looping http
> >>>> requests to repo1.maven.org/maven2
> <http://repo1.maven.org/maven2>
> >>>> <http://repo1.maven.org/maven2> back to my local
> maven
> >>>> repo. So I've made some assumptions about the repo
> >>>> layout that should probably be verified.
> >>>>
> >>>> Best wishes,
> >>>> Paul
> >>>>
> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
> >>>>
> >>>>> Will it hurt anything to commit it now? Or will it
> >>>>> break things?
> >>>>>
> >>>>> --jason
> >>>>>
> >>>>>
> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
> >>>>>
> >>>>>>
> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
> >>>>>>
> >>>>>>> I couldn't do much with the framework assembly
> as it
> >>>>>>> requires a plugin repository with 1.2 plugins and
> >>>>>>> AFAIK there is no such plugin repository available
> >>>>>>> yet. Will you be making the plugins available for
> >>>>>>> 1.2 as you make the release available? If
> not, then
> >>>>>>> perhaps we shouldn't include the framework
> assembly
> >>>>>>> in the distribution.
> >>>>>>
> >>>>>> I updated the plugin catalog stuff in
> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally
> and ran
> >>>>>> some quick tests of plugin download & install from
> >>>>>> maven repo. I'm ready to commit if/when the 1.2
> >>>>>> artifacts are published to central.
> >>>>>>
> >>>>>> Best wishes,
> >>>>>> Paul
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> "I say never be complete, I say stop being perfect, I say
> >>> let... lets evolve, let the chips fall where they may." -
> >>> Tyler Durden
> >>
> >>
> >>
> >>
> >> --
> >> "I say never be complete, I say stop being perfect, I say
> let...
> >> lets evolve, let the chips fall where they may." - Tyler Durden
> >> <geronimo.log>
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> lets
> > evolve, let the chips fall where they may." - Tyler Durden
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden
Re: [discuss] Release Geronimo 1.2
Posted by Christopher Blythe <cj...@gmail.com>.
Doubtful... everything tested fine under light browser based testing. As the
exception suggests, this is a concurrency problem that you would only hit
under load.
On 4/6/07, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
>
> If Matt had no problem deploying and testing DT, could it be a Java
> version or classpath issue?
>
> That could explain the difference in the exception during deployment
> (and the problems during deployment could possibly explain the run time
> problems).
>
> Jay
>
> Christopher Blythe wrote:
> > I use a commercial load driving tool... FYI, I'm fairly certain that
> > G-2.0 has the same issue.
> >
> > On 4/6/07, *David Jencks* < david_jencks@yahoo.com
> > <ma...@yahoo.com>> wrote:
> >
> > I think we need to figure out why the
> > concurrentModificationException is happening before we release. I
> > think that one possible reason is that we are multithreading
> > stateless session bean instances. I hope this isn't the cause....
> > but IMO we need to find out.
> >
> > Chris, how do you run the several clients? manually or with a tool?
> >
> > thanks
> > david jencks
> >
> >
> > On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
> >
> >> Gave it a shot... no luck. As soon as I started 2 clients, the
> >> same exceptions started to pile up. I have attached the
> >> geronimo.log. Also, noticed the following exception during startup.
> >>
> >> 14:05:00,640 ERROR [TransportConnector] Could not accept
> >> connection from /127.0.0.1:28428: java.io.IOException: Wire
> >> format negociation timeout: peer did not send his wire format.
> >> java.io.IOException: Wire format negociation timeout: peer did
> >> not send his wire format.
> >> at org.apache.activemq.transport.WireFormatNegotiator.oneway
> >> (WireFormatNegotiator.java:88)
> >> at
> >> org.apache.activemq.transport.MutexTransport.oneway(
> MutexTransport.java:47)
> >> at org.apache.activemq.broker.TransportConnection.dispatch
> >> (TransportConnection.java:1138)
> >> at
> >> org.apache.activemq.broker.TransportConnection.processDispatch(
> TransportConnection.java:805)
> >> at
> >> org.apache.activemq.broker.TransportConnection.start(
> TransportConnection.java
> >> :885)
> >> at org.apache.activemq.broker.TransportConnector$1.onAccept
> >> (TransportConnector.java:148)
> >> at
> >> org.apache.activemq.transport.tcp.TcpTransportServer.run(
> TcpTransportServer.java:167)
> >> at java.lang.Thread.run (Thread.java:797)
> >>
> >>
> >>
> >> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
> >> <ma...@hogstrom.org>> wrote:
> >>
> >> Only a very light load from a few browsers. One thing to try
> >> is to increase the number of SLSBs in the pool.
> >>
> >> Can you add
> >>
> >> <session>
> >> <ejb-name>TradeJDBC</ejb-name>
> >> <jndi-name>ejb/TradeJDBC</jndi-name>
> >> <cache-size>100</cache-size>
> >> </session>
> >>
> >> to your plan and redeploy. I added some support for multiple
> >> SLSBs in a pool for 1.2 which we did not have before. This
> >> will hopefully make it better and not worse :)
> >>
> >> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
> >>
> >>> Matt...
> >>>
> >>> You mentioned that you deployed DayTrader 1.2... did you
> >>> happen to run it under load? JDBC/Direct mode looks good;
> >>> however, I am still seeing ConcurrentModificationExceptions
> >>> while attempting to run more than 1 client in Session Direct
> >>> mode ( https://issues.apache.org/jira/browse/GERONIMO-2708).
> >>> These exceptions are thrown throughout the duration of the
> >>> run. FYI - I deployed the same ear on Geronimo 1.1.1 and
> >>> didn't have a problem scaling up the users for Session
> >>> Direct mode.
> >>>
> >>> java.util.ConcurrentModificationException
> >>> at java.util.HashMap$HashIterator.remove(HashMap.java:861)
> >>> at
> >>>
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
> >>> (ConnectionTrackingCoordinator.java :127)
> >>> at
> >>>
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
> (<generated>)
> >>> at net.sf.cglib.reflect.FastMethod.invoke
> >>> (FastMethod.java :53)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> FastMethodInvoker.java:38)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(
> GBeanOperation.java:122)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> >>> (GBeanInstance.java:820)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(
> RawInvoker.java:57)
> >>> at
> >>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(
> RawOperationInvoker.java:35)
> >>> at
> >>>
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> >>> (ProxyMethodInterceptor.java:96)
> >>> at
> >>>
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit
> (<generated>)
> >>> at
> >>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
> >>> (NoConnectionEnlistingInterceptor.java:70)
> >>> at
> >>> org.apache.openejb.SystemExceptionInterceptor.invoke(
> SystemExceptionInterceptor.java:35)
> >>> at
> >>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(
> DefaultSubjectInterceptor.java
> >>> :49)
> >>> at
> >>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(
> DefaultStatelessEjbContainer.java:178)
> >>> at
> >>>
> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
> (<generated>)
> >>>
> >>> at
> >>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> FastMethodInvoker.java:38)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> >>> (GBeanOperation.java:122)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
> GBeanInstance.java:820)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(
> RawInvoker.java:57)
> >>> at
> >>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> >>> (RawOperationInvoker.java:35)
> >>> at
> >>>
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(
> ProxyMethodInterceptor.java:96)
> >>> at
> >>>
> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
> >>> (<generated>)
> >>> at
> >>> org.apache.openejb.AbstractEjbDeployment.invoke(
> AbstractEjbDeployment.java:195)
> >>> at
> >>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(
> EJBMethodInterceptor.java:145)
> >>> at
> >>>
> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
> >>> (<generated>)
> >>> at
> >>> org.apache.geronimo.samples.daytrader.TradeAction.login(
> TradeAction.java:449)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.TradeServletAction.doLogin
> >>> <http://web.TradeServletAction.doLogin>(
> TradeServletAction.java:364)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.TradeAppServlet.performTask
> >>> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java
> :126)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.TradeAppServlet.doPost
> >>> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java:91)
> >>> at javax.servlet.http.HttpServlet.service
> >>> (HttpServlet.java:617)
> >>> at
> >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> >>> (ApplicationFilterChain.java:252)
> >>> at
> >>> org.apache.catalina.core.ApplicationFilterChain.doFilter
> >>> (ApplicationFilterChain.java:173)
> >>> at org.apache.geronimo.samples.daytrader.
> >>> web.OrdersAlertFilter.doFilter
> >>> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java
> :91)
> >>> at
> >>>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java
> >>> :202)
> >>> at
> >>> org.apache.catalina.core.ApplicationFilterChain.doFilter
> >>> (ApplicationFilterChain.java:173)
> >>> at
> >>> org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:213)
> >>> at org.apache.catalina.core.StandardContextValve.invoke
> >>> (StandardContextValve.java:178)
> >>> at
> >>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
> DefaultSubjectValve.java:56)
> >>> at
> >>>
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke
> (GeronimoStandardContext.java
> >>> :328)
> >>> at
> >>>
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
> GeronimoBeforeAfterValve.java:47)
> >>> at
> >>> org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:126)
> >>> at org.apache.catalina.valves.ErrorReportValve.invoke
> >>> (ErrorReportValve.java:105)
> >>> at
> >>> org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:107)
> >>> at
> >>> org.apache.catalina.valves.AccessLogValve.invoke(
> AccessLogValve.java:541)
> >>> at org.apache.catalina.connector.CoyoteAdapter.service
> >>> (CoyoteAdapter.java:148)
> >>> at
> >>> org.apache.coyote.http11.Http11Processor.process(
> Http11Processor.java:869)
> >>> at
> >>>
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
> (Http11BaseProtocol.java
> >>> :667)
> >>> at
> >>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> PoolTcpEndpoint.java:527)
> >>> at
> >>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> LeaderFollowerWorkerThread.java:80)
> >>> at
> >>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
> >>> (ThreadPool.java:684)
> >>> at java.lang.Thread.run(Thread.java:797)
> >>>
> >>> On 4/5/07, *Jason Dillon* < jason@planet57.com
> >>> <ma...@planet57.com>> wrote:
> >>>
> >>> Aight, no worries. I still don't fully understand all
> >>> that plugin stuff... yet ;-)
> >>>
> >>> --jason
> >>>
> >>>
> >>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
> >>>
> >>>> The change I have cued up replaces " 1.2-SNAPSHOT" with
> >>>> " 1.2" for all the catalog entries. So it would break
> >>>> anyone using the Geronimo plugin repo from a
> >>>> 1.2-SNAPSHOT server (maybe not a huge deal). Also,
> >>>> I've tested the catalog updates by looping http
> >>>> requests to repo1.maven.org/maven2
> >>>> <http://repo1.maven.org/maven2> back to my local maven
> >>>> repo. So I've made some assumptions about the repo
> >>>> layout that should probably be verified.
> >>>>
> >>>> Best wishes,
> >>>> Paul
> >>>>
> >>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
> >>>>
> >>>>> Will it hurt anything to commit it now? Or will it
> >>>>> break things?
> >>>>>
> >>>>> --jason
> >>>>>
> >>>>>
> >>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
> >>>>>
> >>>>>>
> >>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
> >>>>>>
> >>>>>>> I couldn't do much with the framework assembly as it
> >>>>>>> requires a plugin repository with 1.2 plugins and
> >>>>>>> AFAIK there is no such plugin repository available
> >>>>>>> yet. Will you be making the plugins available for
> >>>>>>> 1.2 as you make the release available? If not, then
> >>>>>>> perhaps we shouldn't include the framework assembly
> >>>>>>> in the distribution.
> >>>>>>
> >>>>>> I updated the plugin catalog stuff in
> >>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally and ran
> >>>>>> some quick tests of plugin download & install from
> >>>>>> maven repo. I'm ready to commit if/when the 1.2
> >>>>>> artifacts are published to central.
> >>>>>>
> >>>>>> Best wishes,
> >>>>>> Paul
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> "I say never be complete, I say stop being perfect, I say
> >>> let... lets evolve, let the chips fall where they may." -
> >>> Tyler Durden
> >>
> >>
> >>
> >>
> >> --
> >> "I say never be complete, I say stop being perfect, I say let...
> >> lets evolve, let the chips fall where they may." - Tyler Durden
> >> <geronimo.log>
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let... lets
> > evolve, let the chips fall where they may." - Tyler Durden
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: [discuss] Release Geronimo 1.2
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
If Matt had no problem deploying and testing DT, could it be a Java
version or classpath issue?
That could explain the difference in the exception during deployment
(and the problems during deployment could possibly explain the run time
problems).
Jay
Christopher Blythe wrote:
> I use a commercial load driving tool... FYI, I'm fairly certain that
> G-2.0 has the same issue.
>
> On 4/6/07, *David Jencks* < david_jencks@yahoo.com
> <ma...@yahoo.com>> wrote:
>
> I think we need to figure out why the
> concurrentModificationException is happening before we release. I
> think that one possible reason is that we are multithreading
> stateless session bean instances. I hope this isn't the cause....
> but IMO we need to find out.
>
> Chris, how do you run the several clients? manually or with a tool?
>
> thanks
> david jencks
>
>
> On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>
>> Gave it a shot... no luck. As soon as I started 2 clients, the
>> same exceptions started to pile up. I have attached the
>> geronimo.log. Also, noticed the following exception during startup.
>>
>> 14:05:00,640 ERROR [TransportConnector] Could not accept
>> connection from /127.0.0.1:28428: java.io.IOException: Wire
>> format negociation timeout: peer did not send his wire format.
>> java.io.IOException: Wire format negociation timeout: peer did
>> not send his wire format.
>> at org.apache.activemq.transport.WireFormatNegotiator.oneway
>> (WireFormatNegotiator.java:88)
>> at
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
>> at org.apache.activemq.broker.TransportConnection.dispatch
>> (TransportConnection.java:1138)
>> at
>> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
>> at
>> org.apache.activemq.broker.TransportConnection.start(TransportConnection.java
>> :885)
>> at org.apache.activemq.broker.TransportConnector$1.onAccept
>> (TransportConnector.java:148)
>> at
>> org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:167)
>> at java.lang.Thread.run (Thread.java:797)
>>
>>
>>
>> On 4/6/07, *Matt Hogstrom* < matt@hogstrom.org
>> <ma...@hogstrom.org>> wrote:
>>
>> Only a very light load from a few browsers. One thing to try
>> is to increase the number of SLSBs in the pool.
>>
>> Can you add
>>
>> <session>
>> <ejb-name>TradeJDBC</ejb-name>
>> <jndi-name>ejb/TradeJDBC</jndi-name>
>> <cache-size>100</cache-size>
>> </session>
>>
>> to your plan and redeploy. I added some support for multiple
>> SLSBs in a pool for 1.2 which we did not have before. This
>> will hopefully make it better and not worse :)
>>
>> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>>
>>> Matt...
>>>
>>> You mentioned that you deployed DayTrader 1.2... did you
>>> happen to run it under load? JDBC/Direct mode looks good;
>>> however, I am still seeing ConcurrentModificationExceptions
>>> while attempting to run more than 1 client in Session Direct
>>> mode ( https://issues.apache.org/jira/browse/GERONIMO-2708).
>>> These exceptions are thrown throughout the duration of the
>>> run. FYI - I deployed the same ear on Geronimo 1.1.1 and
>>> didn't have a problem scaling up the users for Session
>>> Direct mode.
>>>
>>> java.util.ConcurrentModificationException
>>> at java.util.HashMap$HashIterator.remove(HashMap.java:861)
>>> at
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
>>> (ConnectionTrackingCoordinator.java :127)
>>> at
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>>> at net.sf.cglib.reflect.FastMethod.invoke
>>> (FastMethod.java :53)
>>> at
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>>> at
>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>>> at
>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>> (GBeanInstance.java:820)
>>> at
>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>>> at
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>>> at
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>> (ProxyMethodInterceptor.java:96)
>>> at
>>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>>> at
>>> org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>>> (NoConnectionEnlistingInterceptor.java:70)
>>> at
>>> org.apache.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:35)
>>> at
>>> org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java
>>> :49)
>>> at
>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java:178)
>>> at
>>> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke(<generated>)
>>>
>>> at
>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>> at
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>>> at
>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>> (GBeanOperation.java:122)
>>> at
>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
>>> at
>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>>> at
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>> (RawOperationInvoker.java:35)
>>> at
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>>> at
>>> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
>>> (<generated>)
>>> at
>>> org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java:195)
>>> at
>>> org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
>>> at
>>> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
>>> (<generated>)
>>> at
>>> org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java:449)
>>> at org.apache.geronimo.samples.daytrader.
>>> web.TradeServletAction.doLogin
>>> <http://web.TradeServletAction.doLogin>(TradeServletAction.java:364)
>>> at org.apache.geronimo.samples.daytrader.
>>> web.TradeAppServlet.performTask
>>> <http://web.TradeAppServlet.performTask>(TradeAppServlet.java:126)
>>> at org.apache.geronimo.samples.daytrader.
>>> web.TradeAppServlet.doPost
>>> <http://web.TradeAppServlet.doPost>(TradeAppServlet.java:91)
>>> at javax.servlet.http.HttpServlet.service
>>> (HttpServlet.java:617)
>>> at
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>> (ApplicationFilterChain.java:252)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>> (ApplicationFilterChain.java:173)
>>> at org.apache.geronimo.samples.daytrader.
>>> web.OrdersAlertFilter.doFilter
>>> <http://web.OrdersAlertFilter.doFilter>(OrdersAlertFilter.java:91)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java
>>> :202)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>> (ApplicationFilterChain.java:173)
>>> at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>> at org.apache.catalina.core.StandardContextValve.invoke
>>> (StandardContextValve.java:178)
>>> at
>>> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>>> at
>>> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java
>>> :328)
>>> at
>>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
>>> at
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>>> at org.apache.catalina.valves.ErrorReportValve.invoke
>>> (ErrorReportValve.java:105)
>>> at
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>>> at
>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
>>> at org.apache.catalina.connector.CoyoteAdapter.service
>>> (CoyoteAdapter.java:148)
>>> at
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>>> at
>>> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java
>>> :667)
>>> at
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>>> at
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>> at
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
>>> (ThreadPool.java:684)
>>> at java.lang.Thread.run(Thread.java:797)
>>>
>>> On 4/5/07, *Jason Dillon* < jason@planet57.com
>>> <ma...@planet57.com>> wrote:
>>>
>>> Aight, no worries. I still don't fully understand all
>>> that plugin stuff... yet ;-)
>>>
>>> --jason
>>>
>>>
>>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>>
>>>> The change I have cued up replaces " 1.2-SNAPSHOT" with
>>>> " 1.2" for all the catalog entries. So it would break
>>>> anyone using the Geronimo plugin repo from a
>>>> 1.2-SNAPSHOT server (maybe not a huge deal). Also,
>>>> I've tested the catalog updates by looping http
>>>> requests to repo1.maven.org/maven2
>>>> <http://repo1.maven.org/maven2> back to my local maven
>>>> repo. So I've made some assumptions about the repo
>>>> layout that should probably be verified.
>>>>
>>>> Best wishes,
>>>> Paul
>>>>
>>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>>>
>>>>> Will it hurt anything to commit it now? Or will it
>>>>> break things?
>>>>>
>>>>> --jason
>>>>>
>>>>>
>>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>>>>
>>>>>>
>>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>>>>
>>>>>>> I couldn't do much with the framework assembly as it
>>>>>>> requires a plugin repository with 1.2 plugins and
>>>>>>> AFAIK there is no such plugin repository available
>>>>>>> yet. Will you be making the plugins available for
>>>>>>> 1.2 as you make the release available? If not, then
>>>>>>> perhaps we shouldn't include the framework assembly
>>>>>>> in the distribution.
>>>>>>
>>>>>> I updated the plugin catalog stuff in
>>>>>> site/trunk/docs/plugins/geronimo- 1.2 locally and ran
>>>>>> some quick tests of plugin download & install from
>>>>>> maven repo. I'm ready to commit if/when the 1.2
>>>>>> artifacts are published to central.
>>>>>>
>>>>>> Best wishes,
>>>>>> Paul
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> "I say never be complete, I say stop being perfect, I say
>>> let... lets evolve, let the chips fall where they may." -
>>> Tyler Durden
>>
>>
>>
>>
>> --
>> "I say never be complete, I say stop being perfect, I say let...
>> lets evolve, let the chips fall where they may." - Tyler Durden
>> <geronimo.log>
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden
Re: [discuss] Release Geronimo 1.2
Posted by Christopher Blythe <cj...@gmail.com>.
I use a commercial load driving tool... FYI, I'm fairly certain that
G-2.0has the same issue.
On 4/6/07, David Jencks <da...@yahoo.com> wrote:
>
> I think we need to figure out why the concurrentModificationException is
> happening before we release. I think that one possible reason is that we
> are multithreading stateless session bean instances. I hope this isn't the
> cause.... but IMO we need to find out.
> Chris, how do you run the several clients? manually or with a tool?
>
> thanks
> david jencks
>
>
> On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>
> Gave it a shot... no luck. As soon as I started 2 clients, the same
> exceptions started to pile up. I have attached the geronimo.log. Also,
> noticed the following exception during startup.
>
> 14:05:00,640 ERROR [TransportConnector] Could not accept connection from
> /127.0.0.1:28428: java.io.IOException: Wire format negociation timeout:
> peer did not send his wire format.
> java.io.IOException: Wire format negociation timeout: peer did not send
> his wire format.
> at org.apache.activemq.transport.WireFormatNegotiator.oneway (
> WireFormatNegotiator.java:88)
> at org.apache.activemq.transport.MutexTransport.oneway(
> MutexTransport.java:47)
> at org.apache.activemq.broker.TransportConnection.dispatch(
> TransportConnection.java:1138)
> at org.apache.activemq.broker.TransportConnection.processDispatch(
> TransportConnection.java:805)
> at org.apache.activemq.broker.TransportConnection.start(
> TransportConnection.java:885)
> at org.apache.activemq.broker.TransportConnector$1.onAccept (
> TransportConnector.java:148)
> at org.apache.activemq.transport.tcp.TcpTransportServer.run(
> TcpTransportServer.java:167)
> at java.lang.Thread.run(Thread.java:797)
>
>
>
> On 4/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >
> > Only a very light load from a few browsers. One thing to try is to
> > increase the number of SLSBs in the pool.
> >
> > Can you add
> >
> > <session>
> > <ejb-name>TradeJDBC</ejb-name>
> > <jndi-name>ejb/TradeJDBC</jndi-name>
> > <cache-size>100</cache-size>
> > </session>
> >
> > to your plan and redeploy. I added some support for multiple SLSBs in a
> > pool for 1.2 which we did not have before. This will hopefully make it
> > better and not worse :)
> > On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
> >
> > Matt...
> >
> > You mentioned that you deployed DayTrader 1.2... did you happen to run
> > it under load? JDBC/Direct mode looks good; however, I am still seeing
> > ConcurrentModificationExceptions while attempting to run more than 1 client
> > in Session Direct mode (
> > https://issues.apache.org/jira/browse/GERONIMO-2708). These exceptions
> > are thrown throughout the duration of the run. FYI - I deployed the same ear
> > on Geronimo 1.1.1 and didn't have a problem scaling up the users for
> > Session Direct mode.
> >
> > java.util.ConcurrentModificationException
> > at java.util.HashMap$HashIterator.remove(HashMap.java:861)
> > at
> > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit(
> > ConnectionTrackingCoordinator.java:127)
> > at
> > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
> > (<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> > FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(
> > GBeanOperation.java:122)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (
> > GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(
> > RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(
> > RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(
> > ProxyMethodInterceptor.java:96)
> > at
> > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit
> > (<generated>)
> > at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke (
> > NoConnectionEnlistingInterceptor.java:70)
> > at org.apache.openejb.SystemExceptionInterceptor.invoke(
> > SystemExceptionInterceptor.java:35)
> > at org.apache.openejb.security.DefaultSubjectInterceptor.invoke(
> > DefaultSubjectInterceptor.java :49)
> > at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(
> > DefaultStatelessEjbContainer.java:178)
> > at
> > org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke(<generated>)
> >
> > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> > FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (
> > GBeanOperation.java:122)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
> > GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(
> > RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (
> > RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java:96)
> > at
> > org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke(<generated>)
> > at org.apache.openejb.AbstractEjbDeployment.invoke(
> > AbstractEjbDeployment.java:195)
> > at org.apache.openejb.proxy.EJBMethodInterceptor.intercept(
> > EJBMethodInterceptor.java:145)
> > at
> > org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login(<generated>)
> > at org.apache.geronimo.samples.daytrader.TradeAction.login(
> > TradeAction.java:449)
> > at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin
> > (TradeServletAction.java:364)
> > at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask
> > (TradeAppServlet.java:126)
> > at org.apache.geronimo.samples.daytrader. web.TradeAppServlet.doPost
> > (TradeAppServlet.java:91)
> > at javax.servlet.http.HttpServlet.service (HttpServlet.java:617)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java:252)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter (
> > ApplicationFilterChain.java:173)
> > at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter
> > (OrdersAlertFilter.java:91)
> > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java :202)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter (
> > ApplicationFilterChain.java:173)
> > at org.apache.catalina.core.StandardWrapperValve.invoke(
> > StandardWrapperValve.java:213)
> > at org.apache.catalina.core.StandardContextValve.invoke (
> > StandardContextValve.java:178)
> > at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
> > DefaultSubjectValve.java:56)
> > at
> > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke
> > (GeronimoStandardContext.java :328)
> > at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
> > GeronimoBeforeAfterValve.java:47)
> > at org.apache.catalina.core.StandardHostValve.invoke(
> > StandardHostValve.java:126)
> > at org.apache.catalina.valves.ErrorReportValve.invoke (
> > ErrorReportValve.java:105)
> > at org.apache.catalina.core.StandardEngineValve.invoke(
> > StandardEngineValve.java:107)
> > at org.apache.catalina.valves.AccessLogValve.invoke(
> > AccessLogValve.java:541)
> > at org.apache.catalina.connector.CoyoteAdapter.service (
> > CoyoteAdapter.java:148)
> > at org.apache.coyote.http11.Http11Processor.process(
> > Http11Processor.java:869)
> > at
> > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
> > (Http11BaseProtocol.java :667)
> > at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> > PoolTcpEndpoint.java:527)
> > at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> > LeaderFollowerWorkerThread.java:80)
> > at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> > ThreadPool.java:684)
> > at java.lang.Thread.run(Thread.java:797)
> >
> > On 4/5/07, Jason Dillon < jason@planet57.com > wrote:
> > >
> > > Aight, no worries. I still don't fully understand all that plugin
> > > stuff... yet ;-)
> > > --jason
> > >
> > >
> > > On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
> > >
> > > The change I have cued up replaces " 1.2-SNAPSHOT" with " 1.2" for all
> > > the catalog entries. So it would break anyone using the Geronimo plugin
> > > repo from a 1.2-SNAPSHOT server (maybe not a huge deal). Also, I've
> > > tested the catalog updates by looping http requests to
> > > repo1.maven.org/maven2 back to my local maven repo. So I've made some
> > > assumptions about the repo layout that should probably be verified.
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
> > >
> > > Will it hurt anything to commit it now? Or will it break things?
> > > --jason
> > >
> > >
> > > On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
> > >
> > >
> > > On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
> > >
> > > I couldn't do much with the framework assembly as it requires a
> > > plugin repository with 1.2 plugins and AFAIK there is no such plugin
> > > repository available yet. Will you be making the plugins available
> > > for 1.2 as you make the release available? If not, then perhaps we
> > > shouldn't include the framework assembly in the distribution.
> > >
> > >
> > > I updated the plugin catalog stuff in
> > > site/trunk/docs/plugins/geronimo- 1.2 locally and ran some quick tests
> > > of plugin download & install from maven repo. I'm ready to commit if/when
> > > the 1.2 artifacts are published to central.
> > > Best wishes,
> > > Paul
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let... lets
> > evolve, let the chips fall where they may." - Tyler Durden
> >
> >
> >
>
>
> --
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden
> <geronimo.log>
>
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: [discuss] Release Geronimo 1.2
Posted by David Jencks <da...@yahoo.com>.
I think we need to figure out why the concurrentModificationException
is happening before we release. I think that one possible reason is
that we are multithreading stateless session bean instances. I hope
this isn't the cause.... but IMO we need to find out.
Chris, how do you run the several clients? manually or with a tool?
thanks
david jencks
On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
> Gave it a shot... no luck. As soon as I started 2 clients, the same
> exceptions started to pile up. I have attached the geronimo.log.
> Also, noticed the following exception during startup.
>
> 14:05:00,640 ERROR [TransportConnector] Could not accept connection
> from /127.0.0.1:28428: java.io.IOException: Wire format negociation
> timeout: peer did not send his wire format.
> java.io.IOException: Wire format negociation timeout: peer did not
> send his wire format.
> at org.apache.activemq.transport.WireFormatNegotiator.oneway
> (WireFormatNegotiator.java:88)
> at org.apache.activemq.transport.MutexTransport.oneway
> (MutexTransport.java:47)
> at org.apache.activemq.broker.TransportConnection.dispatch
> (TransportConnection.java:1138)
> at
> org.apache.activemq.broker.TransportConnection.processDispatch
> (TransportConnection.java:805)
> at org.apache.activemq.broker.TransportConnection.start
> (TransportConnection.java:885)
> at org.apache.activemq.broker.TransportConnector$1.onAccept
> (TransportConnector.java:148)
> at org.apache.activemq.transport.tcp.TcpTransportServer.run
> (TcpTransportServer.java:167)
> at java.lang.Thread.run(Thread.java:797)
>
>
>
> On 4/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Only a very light load from a few browsers. One thing to try is to
> increase the number of SLSBs in the pool.
>
> Can you add
>
> <session>
> <ejb-name>TradeJDBC</ejb-name>
> <jndi-name>ejb/TradeJDBC</jndi-name>
> <cache-size>100</cache-size>
> </session>
>
> to your plan and redeploy. I added some support for multiple SLSBs
> in a pool for 1.2 which we did not have before. This will
> hopefully make it better and not worse :)
>
> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>
>> Matt...
>>
>> You mentioned that you deployed DayTrader 1.2... did you happen to
>> run it under load? JDBC/Direct mode looks good; however, I am
>> still seeing ConcurrentModificationExceptions while attempting to
>> run more than 1 client in Session Direct mode ( https://
>> issues.apache.org/jira/browse/GERONIMO-2708). These exceptions are
>> thrown throughout the duration of the run. FYI - I deployed the
>> same ear on Geronimo 1.1.1 and didn't have a problem scaling up
>> the users for Session Direct mode.
>>
>> java.util.ConcurrentModificationException
>> at java.util.HashMap$HashIterator.remove(HashMap.java:861)
>> at
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> rackingCoordinator.exit (ConnectionTrackingCoordinator.java:127)
>> at
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>> at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53)
>> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>> (FastMethodInvoker.java:38)
>> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>> (GBeanOperation.java:122)
>> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>> (GBeanInstance.java:820)
>> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>> (RawInvoker.java:57)
>> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>> (RawOperationInvoker.java:35)
>> at
>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>> (ProxyMethodInterceptor.java:96)
>> at
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> racker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>> at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>> (NoConnectionEnlistingInterceptor.java:70)
>> at org.apache.openejb.SystemExceptionInterceptor.invoke
>> (SystemExceptionInterceptor.java:35)
>> at org.apache.openejb.security.DefaultSubjectInterceptor.invoke
>> (DefaultSubjectInterceptor.java :49)
>> at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
>> (DefaultStatelessEjbContainer.java:178)
>> at org.apache.openejb.slsb.DefaultStatelessEjbContainer$
>> $FastClassByCGLIB$$7ad7a562.invoke(<generated>)
>> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>> (FastMethodInvoker.java:38)
>> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>> (GBeanOperation.java:122)
>> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>> (GBeanInstance.java:820)
>> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>> (RawInvoker.java:57)
>> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>> (RawOperationInvoker.java:35)
>> at
>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>> (ProxyMethodInterceptor.java:96)
>> at org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$
>> $5c554f35.invoke (<generated>)
>> at org.apache.openejb.AbstractEjbDeployment.invoke
>> (AbstractEjbDeployment.java:195)
>> at org.apache.openejb.proxy.EJBMethodInterceptor.intercept
>> (EJBMethodInterceptor.java:145)
>> at org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$
>> $f5a9c1b2.login (<generated>)
>> at org.apache.geronimo.samples.daytrader.TradeAction.login
>> (TradeAction.java:449)
>> at org.apache.geronimo.samples.daytrader.
>> web.TradeServletAction.doLogin(TradeServletAction.java:364)
>> at org.apache.geronimo.samples.daytrader.
>> web.TradeAppServlet.performTask(TradeAppServlet.java:126)
>> at org.apache.geronimo.samples.daytrader.
>> web.TradeAppServlet.doPost(TradeAppServlet.java:91)
>> at javax.servlet.http.HttpServlet.service (HttpServlet.java:617)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java:252)
>> at org.apache.catalina.core.ApplicationFilterChain.doFilter
>> (ApplicationFilterChain.java:173)
>> at org.apache.geronimo.samples.daytrader.
>> web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java :202)
>> at org.apache.catalina.core.ApplicationFilterChain.doFilter
>> (ApplicationFilterChain.java:173)
>> at org.apache.catalina.core.StandardWrapperValve.invoke
>> (StandardWrapperValve.java:213)
>> at org.apache.catalina.core.StandardContextValve.invoke
>> (StandardContextValve.java:178)
>> at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
>> (DefaultSubjectValve.java:56)
>> at org.apache.geronimo.tomcat.GeronimoStandardContext
>> $SystemMethodValve.invoke(GeronimoStandardContext.java :328)
>> at
>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>> (GeronimoBeforeAfterValve.java:47)
>> at org.apache.catalina.core.StandardHostValve.invoke
>> (StandardHostValve.java:126)
>> at org.apache.catalina.valves.ErrorReportValve.invoke
>> (ErrorReportValve.java:105)
>> at org.apache.catalina.core.StandardEngineValve.invoke
>> (StandardEngineValve.java:107)
>> at org.apache.catalina.valves.AccessLogValve.invoke
>> (AccessLogValve.java:541)
>> at org.apache.catalina.connector.CoyoteAdapter.service
>> (CoyoteAdapter.java:148)
>> at org.apache.coyote.http11.Http11Processor.process
>> (Http11Processor.java:869)
>> at org.apache.coyote.http11.Http11BaseProtocol
>> $Http11ConnectionHandler.processConnection
>> (Http11BaseProtocol.java :667)
>> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
>> (PoolTcpEndpoint.java:527)
>> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
>> (LeaderFollowerWorkerThread.java:80)
>> at org.apache.tomcat.util.threads.ThreadPool
>> $ControlRunnable.run (ThreadPool.java:684)
>> at java.lang.Thread.run(Thread.java:797)
>>
>> On 4/5/07, Jason Dillon < jason@planet57.com > wrote:
>> Aight, no worries. I still don't fully understand all that plugin
>> stuff... yet ;-)
>>
>> --jason
>>
>>
>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>
>>> The change I have cued up replaces " 1.2-SNAPSHOT" with " 1.2"
>>> for all the catalog entries. So it would break anyone using the
>>> Geronimo plugin repo from a 1.2-SNAPSHOT server (maybe not a huge
>>> deal). Also, I've tested the catalog updates by looping http
>>> requests to repo1.maven.org/maven2 back to my local maven repo.
>>> So I've made some assumptions about the repo layout that should
>>> probably be verified.
>>>
>>> Best wishes,
>>> Paul
>>>
>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>>
>>>> Will it hurt anything to commit it now? Or will it break things?
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>>>
>>>>>
>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>>>
>>>>>> I couldn't do much with the framework assembly as it requires
>>>>>> a plugin repository with 1.2 plugins and AFAIK there is no
>>>>>> such plugin repository available yet. Will you be making the
>>>>>> plugins available for 1.2 as you make the release available?
>>>>>> If not, then perhaps we shouldn't include the framework
>>>>>> assembly in the distribution.
>>>>>
>>>>> I updated the plugin catalog stuff in site/trunk/docs/plugins/
>>>>> geronimo- 1.2 locally and ran some quick tests of plugin
>>>>> download & install from maven repo. I'm ready to commit if/
>>>>> when the 1.2 artifacts are published to central.
>>>>>
>>>>> Best wishes,
>>>>> Paul
>>>>>
>>>>
>>>
>>
>>
>>
>>
>> --
>> "I say never be complete, I say stop being perfect, I say let...
>> lets evolve, let the chips fall where they may." - Tyler Durden
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
> <geronimo.log>
Re: [discuss] Release Geronimo 1.2
Posted by Christopher Blythe <cj...@gmail.com>.
<external-rar>org.apache.geronimo.modules
/ge-activemq-rar/1.2/rar</external-rar>
On 4/6/07, Jason Dillon <ja...@planet57.com> wrote:
>
> What version of AMQ is DT using?
> --jason
>
>
> On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
>
> Gave it a shot... no luck. As soon as I started 2 clients, the same
> exceptions started to pile up. I have attached the geronimo.log. Also,
> noticed the following exception during startup.
>
> 14:05:00,640 ERROR [TransportConnector] Could not accept connection from
> /127.0.0.1:28428: java.io.IOException: Wire format negociation timeout:
> peer did not send his wire format.
> java.io.IOException: Wire format negociation timeout: peer did not send
> his wire format.
> at org.apache.activemq.transport.WireFormatNegotiator.oneway (
> WireFormatNegotiator.java:88)
> at org.apache.activemq.transport.MutexTransport.oneway(
> MutexTransport.java:47)
> at org.apache.activemq.broker.TransportConnection.dispatch(
> TransportConnection.java:1138)
> at org.apache.activemq.broker.TransportConnection.processDispatch(
> TransportConnection.java:805)
> at org.apache.activemq.broker.TransportConnection.start(
> TransportConnection.java:885)
> at org.apache.activemq.broker.TransportConnector$1.onAccept (
> TransportConnector.java:148)
> at org.apache.activemq.transport.tcp.TcpTransportServer.run(
> TcpTransportServer.java:167)
> at java.lang.Thread.run(Thread.java:797)
>
>
>
> On 4/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >
> > Only a very light load from a few browsers. One thing to try is to
> > increase the number of SLSBs in the pool.
> >
> > Can you add
> >
> > <session>
> > <ejb-name>TradeJDBC</ejb-name>
> > <jndi-name>ejb/TradeJDBC</jndi-name>
> > <cache-size>100</cache-size>
> > </session>
> >
> > to your plan and redeploy. I added some support for multiple SLSBs in a
> > pool for 1.2 which we did not have before. This will hopefully make it
> > better and not worse :)
> > On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
> >
> > Matt...
> >
> > You mentioned that you deployed DayTrader 1.2... did you happen to run
> > it under load? JDBC/Direct mode looks good; however, I am still seeing
> > ConcurrentModificationExceptions while attempting to run more than 1 client
> > in Session Direct mode (
> > https://issues.apache.org/jira/browse/GERONIMO-2708). These exceptions
> > are thrown throughout the duration of the run. FYI - I deployed the same ear
> > on Geronimo 1.1.1 and didn't have a problem scaling up the users for
> > Session Direct mode.
> >
> > java.util.ConcurrentModificationException
> > at java.util.HashMap$HashIterator.remove(HashMap.java:861)
> > at
> > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit(
> > ConnectionTrackingCoordinator.java:127)
> > at
> > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
> > (<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> > FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(
> > GBeanOperation.java:122)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (
> > GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(
> > RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(
> > RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(
> > ProxyMethodInterceptor.java:96)
> > at
> > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit
> > (<generated>)
> > at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke (
> > NoConnectionEnlistingInterceptor.java:70)
> > at org.apache.openejb.SystemExceptionInterceptor.invoke(
> > SystemExceptionInterceptor.java:35)
> > at org.apache.openejb.security.DefaultSubjectInterceptor.invoke(
> > DefaultSubjectInterceptor.java :49)
> > at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(
> > DefaultStatelessEjbContainer.java:178)
> > at
> > org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke(<generated>)
> >
> > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> > FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (
> > GBeanOperation.java:122)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
> > GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(
> > RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (
> > RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java:96)
> > at
> > org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke(<generated>)
> > at org.apache.openejb.AbstractEjbDeployment.invoke(
> > AbstractEjbDeployment.java:195)
> > at org.apache.openejb.proxy.EJBMethodInterceptor.intercept(
> > EJBMethodInterceptor.java:145)
> > at
> > org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login(<generated>)
> > at org.apache.geronimo.samples.daytrader.TradeAction.login(
> > TradeAction.java:449)
> > at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin
> > (TradeServletAction.java:364)
> > at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask
> > (TradeAppServlet.java:126)
> > at org.apache.geronimo.samples.daytrader. web.TradeAppServlet.doPost
> > (TradeAppServlet.java:91)
> > at javax.servlet.http.HttpServlet.service (HttpServlet.java:617)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java:252)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter (
> > ApplicationFilterChain.java:173)
> > at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter
> > (OrdersAlertFilter.java:91)
> > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> > ApplicationFilterChain.java :202)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter (
> > ApplicationFilterChain.java:173)
> > at org.apache.catalina.core.StandardWrapperValve.invoke(
> > StandardWrapperValve.java:213)
> > at org.apache.catalina.core.StandardContextValve.invoke (
> > StandardContextValve.java:178)
> > at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
> > DefaultSubjectValve.java:56)
> > at
> > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke
> > (GeronimoStandardContext.java :328)
> > at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
> > GeronimoBeforeAfterValve.java:47)
> > at org.apache.catalina.core.StandardHostValve.invoke(
> > StandardHostValve.java:126)
> > at org.apache.catalina.valves.ErrorReportValve.invoke (
> > ErrorReportValve.java:105)
> > at org.apache.catalina.core.StandardEngineValve.invoke(
> > StandardEngineValve.java:107)
> > at org.apache.catalina.valves.AccessLogValve.invoke(
> > AccessLogValve.java:541)
> > at org.apache.catalina.connector.CoyoteAdapter.service (
> > CoyoteAdapter.java:148)
> > at org.apache.coyote.http11.Http11Processor.process(
> > Http11Processor.java:869)
> > at
> > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
> > (Http11BaseProtocol.java :667)
> > at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> > PoolTcpEndpoint.java:527)
> > at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> > LeaderFollowerWorkerThread.java:80)
> > at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> > ThreadPool.java:684)
> > at java.lang.Thread.run(Thread.java:797)
> >
> > On 4/5/07, Jason Dillon < jason@planet57.com > wrote:
> > >
> > > Aight, no worries. I still don't fully understand all that plugin
> > > stuff... yet ;-)
> > > --jason
> > >
> > >
> > > On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
> > >
> > > The change I have cued up replaces " 1.2-SNAPSHOT" with " 1.2" for all
> > > the catalog entries. So it would break anyone using the Geronimo plugin
> > > repo from a 1.2-SNAPSHOT server (maybe not a huge deal). Also, I've
> > > tested the catalog updates by looping http requests to
> > > repo1.maven.org/maven2 back to my local maven repo. So I've made some
> > > assumptions about the repo layout that should probably be verified.
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
> > >
> > > Will it hurt anything to commit it now? Or will it break things?
> > > --jason
> > >
> > >
> > > On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
> > >
> > >
> > > On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
> > >
> > > I couldn't do much with the framework assembly as it requires a
> > > plugin repository with 1.2 plugins and AFAIK there is no such plugin
> > > repository available yet. Will you be making the plugins available
> > > for 1.2 as you make the release available? If not, then perhaps we
> > > shouldn't include the framework assembly in the distribution.
> > >
> > >
> > > I updated the plugin catalog stuff in
> > > site/trunk/docs/plugins/geronimo- 1.2 locally and ran some quick tests
> > > of plugin download & install from maven repo. I'm ready to commit if/when
> > > the 1.2 artifacts are published to central.
> > > Best wishes,
> > > Paul
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let... lets
> > evolve, let the chips fall where they may." - Tyler Durden
> >
> >
> >
>
>
> --
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden
> <geronimo.log>
>
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: [discuss] Release Geronimo 1.2
Posted by Jason Dillon <ja...@planet57.com>.
What version of AMQ is DT using?
--jason
On Apr 6, 2007, at 11:09 AM, Christopher Blythe wrote:
> Gave it a shot... no luck. As soon as I started 2 clients, the same
> exceptions started to pile up. I have attached the geronimo.log.
> Also, noticed the following exception during startup.
>
> 14:05:00,640 ERROR [TransportConnector] Could not accept connection
> from /127.0.0.1:28428: java.io.IOException: Wire format negociation
> timeout: peer did not send his wire format.
> java.io.IOException: Wire format negociation timeout: peer did not
> send his wire format.
> at org.apache.activemq.transport.WireFormatNegotiator.oneway
> (WireFormatNegotiator.java:88)
> at org.apache.activemq.transport.MutexTransport.oneway
> (MutexTransport.java:47)
> at org.apache.activemq.broker.TransportConnection.dispatch
> (TransportConnection.java:1138)
> at
> org.apache.activemq.broker.TransportConnection.processDispatch
> (TransportConnection.java:805)
> at org.apache.activemq.broker.TransportConnection.start
> (TransportConnection.java:885)
> at org.apache.activemq.broker.TransportConnector$1.onAccept
> (TransportConnector.java:148)
> at org.apache.activemq.transport.tcp.TcpTransportServer.run
> (TcpTransportServer.java:167)
> at java.lang.Thread.run(Thread.java:797)
>
>
>
> On 4/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Only a very light load from a few browsers. One thing to try is to
> increase the number of SLSBs in the pool.
>
> Can you add
>
> <session>
> <ejb-name>TradeJDBC</ejb-name>
> <jndi-name>ejb/TradeJDBC</jndi-name>
> <cache-size>100</cache-size>
> </session>
>
> to your plan and redeploy. I added some support for multiple SLSBs
> in a pool for 1.2 which we did not have before. This will
> hopefully make it better and not worse :)
>
> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>
>> Matt...
>>
>> You mentioned that you deployed DayTrader 1.2... did you happen to
>> run it under load? JDBC/Direct mode looks good; however, I am
>> still seeing ConcurrentModificationExceptions while attempting to
>> run more than 1 client in Session Direct mode ( https://
>> issues.apache.org/jira/browse/GERONIMO-2708). These exceptions are
>> thrown throughout the duration of the run. FYI - I deployed the
>> same ear on Geronimo 1.1.1 and didn't have a problem scaling up
>> the users for Session Direct mode.
>>
>> java.util.ConcurrentModificationException
>> at java.util.HashMap$HashIterator.remove(HashMap.java:861)
>> at
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> rackingCoordinator.exit (ConnectionTrackingCoordinator.java:127)
>> at
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
>> at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53)
>> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>> (FastMethodInvoker.java:38)
>> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>> (GBeanOperation.java:122)
>> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>> (GBeanInstance.java:820)
>> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>> (RawInvoker.java:57)
>> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>> (RawOperationInvoker.java:35)
>> at
>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>> (ProxyMethodInterceptor.java:96)
>> at
>> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT
>> racker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
>> at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
>> (NoConnectionEnlistingInterceptor.java:70)
>> at org.apache.openejb.SystemExceptionInterceptor.invoke
>> (SystemExceptionInterceptor.java:35)
>> at org.apache.openejb.security.DefaultSubjectInterceptor.invoke
>> (DefaultSubjectInterceptor.java :49)
>> at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
>> (DefaultStatelessEjbContainer.java:178)
>> at org.apache.openejb.slsb.DefaultStatelessEjbContainer$
>> $FastClassByCGLIB$$7ad7a562.invoke(<generated>)
>> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>> (FastMethodInvoker.java:38)
>> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>> (GBeanOperation.java:122)
>> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>> (GBeanInstance.java:820)
>> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>> (RawInvoker.java:57)
>> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>> (RawOperationInvoker.java:35)
>> at
>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>> (ProxyMethodInterceptor.java:96)
>> at org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$
>> $5c554f35.invoke (<generated>)
>> at org.apache.openejb.AbstractEjbDeployment.invoke
>> (AbstractEjbDeployment.java:195)
>> at org.apache.openejb.proxy.EJBMethodInterceptor.intercept
>> (EJBMethodInterceptor.java:145)
>> at org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$
>> $f5a9c1b2.login (<generated>)
>> at org.apache.geronimo.samples.daytrader.TradeAction.login
>> (TradeAction.java:449)
>> at org.apache.geronimo.samples.daytrader.
>> web.TradeServletAction.doLogin(TradeServletAction.java:364)
>> at org.apache.geronimo.samples.daytrader.
>> web.TradeAppServlet.performTask(TradeAppServlet.java:126)
>> at org.apache.geronimo.samples.daytrader.
>> web.TradeAppServlet.doPost(TradeAppServlet.java:91)
>> at javax.servlet.http.HttpServlet.service (HttpServlet.java:617)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java:252)
>> at org.apache.catalina.core.ApplicationFilterChain.doFilter
>> (ApplicationFilterChain.java:173)
>> at org.apache.geronimo.samples.daytrader.
>> web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java :202)
>> at org.apache.catalina.core.ApplicationFilterChain.doFilter
>> (ApplicationFilterChain.java:173)
>> at org.apache.catalina.core.StandardWrapperValve.invoke
>> (StandardWrapperValve.java:213)
>> at org.apache.catalina.core.StandardContextValve.invoke
>> (StandardContextValve.java:178)
>> at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
>> (DefaultSubjectValve.java:56)
>> at org.apache.geronimo.tomcat.GeronimoStandardContext
>> $SystemMethodValve.invoke(GeronimoStandardContext.java :328)
>> at
>> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
>> (GeronimoBeforeAfterValve.java:47)
>> at org.apache.catalina.core.StandardHostValve.invoke
>> (StandardHostValve.java:126)
>> at org.apache.catalina.valves.ErrorReportValve.invoke
>> (ErrorReportValve.java:105)
>> at org.apache.catalina.core.StandardEngineValve.invoke
>> (StandardEngineValve.java:107)
>> at org.apache.catalina.valves.AccessLogValve.invoke
>> (AccessLogValve.java:541)
>> at org.apache.catalina.connector.CoyoteAdapter.service
>> (CoyoteAdapter.java:148)
>> at org.apache.coyote.http11.Http11Processor.process
>> (Http11Processor.java:869)
>> at org.apache.coyote.http11.Http11BaseProtocol
>> $Http11ConnectionHandler.processConnection
>> (Http11BaseProtocol.java :667)
>> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
>> (PoolTcpEndpoint.java:527)
>> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
>> (LeaderFollowerWorkerThread.java:80)
>> at org.apache.tomcat.util.threads.ThreadPool
>> $ControlRunnable.run (ThreadPool.java:684)
>> at java.lang.Thread.run(Thread.java:797)
>>
>> On 4/5/07, Jason Dillon < jason@planet57.com > wrote:
>> Aight, no worries. I still don't fully understand all that plugin
>> stuff... yet ;-)
>>
>> --jason
>>
>>
>> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>>
>>> The change I have cued up replaces " 1.2-SNAPSHOT" with " 1.2"
>>> for all the catalog entries. So it would break anyone using the
>>> Geronimo plugin repo from a 1.2-SNAPSHOT server (maybe not a huge
>>> deal). Also, I've tested the catalog updates by looping http
>>> requests to repo1.maven.org/maven2 back to my local maven repo.
>>> So I've made some assumptions about the repo layout that should
>>> probably be verified.
>>>
>>> Best wishes,
>>> Paul
>>>
>>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>>
>>>> Will it hurt anything to commit it now? Or will it break things?
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>>>
>>>>>
>>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>>>
>>>>>> I couldn't do much with the framework assembly as it requires
>>>>>> a plugin repository with 1.2 plugins and AFAIK there is no
>>>>>> such plugin repository available yet. Will you be making the
>>>>>> plugins available for 1.2 as you make the release available?
>>>>>> If not, then perhaps we shouldn't include the framework
>>>>>> assembly in the distribution.
>>>>>
>>>>> I updated the plugin catalog stuff in site/trunk/docs/plugins/
>>>>> geronimo- 1.2 locally and ran some quick tests of plugin
>>>>> download & install from maven repo. I'm ready to commit if/
>>>>> when the 1.2 artifacts are published to central.
>>>>>
>>>>> Best wishes,
>>>>> Paul
>>>>>
>>>>
>>>
>>
>>
>>
>>
>> --
>> "I say never be complete, I say stop being perfect, I say let...
>> lets evolve, let the chips fall where they may." - Tyler Durden
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
> <geronimo.log>
Re: [discuss] Release Geronimo 1.2
Posted by Christopher Blythe <cj...@gmail.com>.
Gave it a shot... no luck. As soon as I started 2 clients, the same
exceptions started to pile up. I have attached the geronimo.log. Also,
noticed the following exception during startup.
14:05:00,640 ERROR [TransportConnector] Could not accept connection from
/127.0.0.1:28428: java.io.IOException: Wire format negociation timeout: peer
did not send his wire format.
java.io.IOException: Wire format negociation timeout: peer did not send his
wire format.
at org.apache.activemq.transport.WireFormatNegotiator.oneway(
WireFormatNegotiator.java:88)
at org.apache.activemq.transport.MutexTransport.oneway(
MutexTransport.java:47)
at org.apache.activemq.broker.TransportConnection.dispatch(
TransportConnection.java:1138)
at org.apache.activemq.broker.TransportConnection.processDispatch(
TransportConnection.java:805)
at org.apache.activemq.broker.TransportConnection.start(
TransportConnection.java:885)
at org.apache.activemq.broker.TransportConnector$1.onAccept(
TransportConnector.java:148)
at org.apache.activemq.transport.tcp.TcpTransportServer.run(
TcpTransportServer.java:167)
at java.lang.Thread.run(Thread.java:797)
On 4/6/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> Only a very light load from a few browsers. One thing to try is to
> increase the number of SLSBs in the pool.
>
> Can you add
>
> <session>
> <ejb-name>TradeJDBC</ejb-name>
> <jndi-name>ejb/TradeJDBC</jndi-name>
> <cache-size>100</cache-size>
> </session>
>
> to your plan and redeploy. I added some support for multiple SLSBs in a
> pool for 1.2 which we did not have before. This will hopefully make it
> better and not worse :)
> On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
>
> Matt...
>
> You mentioned that you deployed DayTrader 1.2... did you happen to run it
> under load? JDBC/Direct mode looks good; however, I am still seeing
> ConcurrentModificationExceptions while attempting to run more than 1 client
> in Session Direct mode (
> https://issues.apache.org/jira/browse/GERONIMO-2708). These exceptions are
> thrown throughout the duration of the run. FYI - I deployed the same ear on
> Geronimo 1.1.1 and didn't have a problem scaling up the users for Session
> Direct mode.
>
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.remove(HashMap.java:861)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit(
> ConnectionTrackingCoordinator.java:127)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
> (<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(
> GBeanOperation.java:122)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (
> GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
> :57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(
> RawOperationInvoker.java:35)
> at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (
> ProxyMethodInterceptor.java:96)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit
> (<generated>)
> at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke (
> NoConnectionEnlistingInterceptor.java:70)
> at org.apache.openejb.SystemExceptionInterceptor.invoke(
> SystemExceptionInterceptor.java:35)
> at org.apache.openejb.security.DefaultSubjectInterceptor.invoke(
> DefaultSubjectInterceptor.java :49)
> at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(
> DefaultStatelessEjbContainer.java:178)
> at
> org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke(<generated>)
>
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
> FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (
> GBeanOperation.java:122)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
> GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
> :57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (
> RawOperationInvoker.java:35)
> at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(
> ProxyMethodInterceptor.java:96)
> at
> org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke(<generated>)
> at org.apache.openejb.AbstractEjbDeployment.invoke(
> AbstractEjbDeployment.java:195)
> at org.apache.openejb.proxy.EJBMethodInterceptor.intercept(
> EJBMethodInterceptor.java:145)
> at
> org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login(<generated>)
> at org.apache.geronimo.samples.daytrader.TradeAction.login(
> TradeAction.java:449)
> at org.apache.geronimo.samples.daytrader.
> web.TradeServletAction.doLogin(TradeServletAction.java:364)
> at org.apache.geronimo.samples.daytrader.
> web.TradeAppServlet.performTask(TradeAppServlet.java:126)
> at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(
> TradeAppServlet.java:91)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter (
> ApplicationFilterChain.java:173)
> at org.apache.geronimo.samples.daytrader.
> web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java :202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke (
> StandardContextValve.java:178)
> at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
> DefaultSubjectValve.java:56)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke
> (GeronimoStandardContext.java :328)
> at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
> GeronimoBeforeAfterValve.java:47)
> at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke (
> ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:107)
> at org.apache.catalina.valves.AccessLogValve.invoke(
> AccessLogValve.java:541)
> at org.apache.catalina.connector.CoyoteAdapter.service (
> CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process(
> Http11Processor.java:869)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
> (Http11BaseProtocol.java :667)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> LeaderFollowerWorkerThread.java:80)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:797)
>
> On 4/5/07, Jason Dillon <jason@planet57.com > wrote:
> >
> > Aight, no worries. I still don't fully understand all that plugin
> > stuff... yet ;-)
> > --jason
> >
> >
> > On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
> >
> > The change I have cued up replaces " 1.2-SNAPSHOT" with "1.2" for all
> > the catalog entries. So it would break anyone using the Geronimo plugin
> > repo from a 1.2-SNAPSHOT server (maybe not a huge deal). Also, I've
> > tested the catalog updates by looping http requests to
> > repo1.maven.org/maven2 back to my local maven repo. So I've made some
> > assumptions about the repo layout that should probably be verified.
> >
> > Best wishes,
> > Paul
> >
> > On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
> >
> > Will it hurt anything to commit it now? Or will it break things?
> > --jason
> >
> >
> > On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
> >
> >
> > On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
> >
> > I couldn't do much with the framework assembly as it requires a plugin
> > repository with 1.2 plugins and AFAIK there is no such plugin repository
> > available yet. Will you be making the plugins available for 1.2 as you
> > make the release available? If not, then perhaps we shouldn't include
> > the framework assembly in the distribution.
> >
> >
> > I updated the plugin catalog stuff in site/trunk/docs/plugins/geronimo-
> > 1.2 locally and ran some quick tests of plugin download & install from
> > maven repo. I'm ready to commit if/when the 1.2 artifacts are published
> > to central.
> > Best wishes,
> > Paul
> >
> >
> >
> >
> >
>
>
> --
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden
>
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: [discuss] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Only a very light load from a few browsers. One thing to try is to
increase the number of SLSBs in the pool.
Can you add
<session>
<ejb-name>TradeJDBC</ejb-name>
<jndi-name>ejb/TradeJDBC</jndi-name>
<cache-size>100</cache-size>
</session>
to your plan and redeploy. I added some support for multiple SLSBs
in a pool for 1.2 which we did not have before. This will hopefully
make it better and not worse :)
On Apr 6, 2007, at 11:32 AM, Christopher Blythe wrote:
> Matt...
>
> You mentioned that you deployed DayTrader 1.2... did you happen to
> run it under load? JDBC/Direct mode looks good; however, I am still
> seeing ConcurrentModificationExceptions while attempting to run
> more than 1 client in Session Direct mode ( https://
> issues.apache.org/jira/browse/GERONIMO-2708). These exceptions are
> thrown throughout the duration of the run. FYI - I deployed the
> same ear on Geronimo 1.1.1 and didn't have a problem scaling up the
> users for Session Direct mode.
>
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.remove(HashMap.java:861)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTr
> ackingCoordinator.exit (ConnectionTrackingCoordinator.java:127)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTr
> ackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:122)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:35)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTr
> acker$$EnhancerByCGLIB$$b6b1324a.exit(<generated>)
> at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
> (NoConnectionEnlistingInterceptor.java:70)
> at org.apache.openejb.SystemExceptionInterceptor.invoke
> (SystemExceptionInterceptor.java:35)
> at org.apache.openejb.security.DefaultSubjectInterceptor.invoke
> (DefaultSubjectInterceptor.java :49)
> at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke
> (DefaultStatelessEjbContainer.java:178)
> at org.apache.openejb.slsb.DefaultStatelessEjbContainer$
> $FastClassByCGLIB$$7ad7a562.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:122)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:35)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$
> $5c554f35.invoke (<generated>)
> at org.apache.openejb.AbstractEjbDeployment.invoke
> (AbstractEjbDeployment.java:195)
> at org.apache.openejb.proxy.EJBMethodInterceptor.intercept
> (EJBMethodInterceptor.java:145)
> at org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$
> $f5a9c1b2.login (<generated>)
> at org.apache.geronimo.samples.daytrader.TradeAction.login
> (TradeAction.java:449)
> at
> org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin
> (TradeServletAction.java:364)
> at
> org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(
> TradeAppServlet.java:126)
> at
> org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost
> (TradeAppServlet.java:91)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:173)
> at
> org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter
> (OrdersAlertFilter.java:91)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java :202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:178)
> at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
> (DefaultSubjectValve.java:56)
> at org.apache.geronimo.tomcat.GeronimoStandardContext
> $SystemMethodValve.invoke(GeronimoStandardContext.java :328)
> at
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke
> (GeronimoBeforeAfterValve.java:47)
> at org.apache.catalina.core.StandardHostValve.invoke
> (StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke
> (ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke
> (StandardEngineValve.java:107)
> at org.apache.catalina.valves.AccessLogValve.invoke
> (AccessLogValve.java:541)
> at org.apache.catalina.connector.CoyoteAdapter.service
> (CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process
> (Http11Processor.java:869)
> at org.apache.coyote.http11.Http11BaseProtocol
> $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java :
> 667)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
> (PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
> (LeaderFollowerWorkerThread.java:80)
> at org.apache.tomcat.util.threads.ThreadPool
> $ControlRunnable.run (ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:797)
>
> On 4/5/07, Jason Dillon <jason@planet57.com > wrote:
> Aight, no worries. I still don't fully understand all that plugin
> stuff... yet ;-)
>
> --jason
>
>
> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>
>> The change I have cued up replaces " 1.2-SNAPSHOT" with "1.2" for
>> all the catalog entries. So it would break anyone using the
>> Geronimo plugin repo from a 1.2-SNAPSHOT server (maybe not a huge
>> deal). Also, I've tested the catalog updates by looping http
>> requests to repo1.maven.org/maven2 back to my local maven repo.
>> So I've made some assumptions about the repo layout that should
>> probably be verified.
>>
>> Best wishes,
>> Paul
>>
>> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>>
>>> Will it hurt anything to commit it now? Or will it break things?
>>>
>>> --jason
>>>
>>>
>>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>>
>>>>
>>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>>
>>>>> I couldn't do much with the framework assembly as it requires a
>>>>> plugin repository with 1.2 plugins and AFAIK there is no such
>>>>> plugin repository available yet. Will you be making the
>>>>> plugins available for 1.2 as you make the release available?
>>>>> If not, then perhaps we shouldn't include the framework
>>>>> assembly in the distribution.
>>>>
>>>> I updated the plugin catalog stuff in site/trunk/docs/plugins/
>>>> geronimo- 1.2 locally and ran some quick tests of plugin
>>>> download & install from maven repo. I'm ready to commit if/when
>>>> the 1.2 artifacts are published to central.
>>>>
>>>> Best wishes,
>>>> Paul
>>>>
>>>
>>
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: [vote] Release Geronimo 1.2
Posted by Christopher Blythe <cj...@gmail.com>.
Matt...
You mentioned that you deployed DayTrader 1.2... did you happen to run it
under load? JDBC/Direct mode looks good; however, I am still seeing
ConcurrentModificationExceptions while attempting to run more than 1 client
in Session Direct mode (https://issues.apache.org/jira/browse/GERONIMO-2708).
These exceptions are thrown throughout the duration of the run. FYI - I
deployed the same ear on Geronimo 1.1.1 and didn't have a problem scaling up
the users for Session Direct mode.
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.remove(HashMap.java:861)
at
org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit
(ConnectionTrackingCoordinator.java:127)
at
org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke
(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(
GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
GBeanInstance.java:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(
RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(
ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$b6b1324a.exit
(<generated>)
at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke(
NoConnectionEnlistingInterceptor.java:70)
at org.apache.openejb.SystemExceptionInterceptor.invoke(
SystemExceptionInterceptor.java:35)
at org.apache.openejb.security.DefaultSubjectInterceptor.invoke(
DefaultSubjectInterceptor.java:49)
at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(
DefaultStatelessEjbContainer.java:178)
at
org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke
(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(
FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(
GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
GBeanInstance.java:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java
:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(
RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(
ProxyMethodInterceptor.java:96)
at
org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$5c554f35.invoke
(<generated>)
at org.apache.openejb.AbstractEjbDeployment.invoke(
AbstractEjbDeployment.java:195)
at org.apache.openejb.proxy.EJBMethodInterceptor.intercept(
EJBMethodInterceptor.java:145)
at
org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$f5a9c1b2.login
(<generated>)
at org.apache.geronimo.samples.daytrader.TradeAction.login(
TradeAction.java:449)
at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(
TradeServletAction.java:364)
at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask
(TradeAppServlet.java:126)
at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(
TradeAppServlet.java:91)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(
OrdersAlertFilter.java:91)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:178)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(
GeronimoStandardContext.java:328)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
GeronimoBeforeAfterValve.java:47)
at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java
:541)
at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:797)
On 4/5/07, Jason Dillon <ja...@planet57.com> wrote:
>
> Aight, no worries. I still don't fully understand all that plugin
> stuff... yet ;-)
> --jason
>
>
> On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
>
> The change I have cued up replaces "1.2-SNAPSHOT" with "1.2" for all the
> catalog entries. So it would break anyone using the Geronimo plugin repo
> from a 1.2-SNAPSHOT server (maybe not a huge deal). Also, I've tested the
> catalog updates by looping http requests to repo1.maven.org/maven2 back to
> my local maven repo. So I've made some assumptions about the repo layout
> that should probably be verified.
>
> Best wishes,
> Paul
>
> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>
> Will it hurt anything to commit it now? Or will it break things?
> --jason
>
>
> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>
>
> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>
> I couldn't do much with the framework assembly as it requires a plugin
> repository with 1.2 plugins and AFAIK there is no such plugin repository
> available yet. Will you be making the plugins available for 1.2 as you
> make the release available? If not, then perhaps we shouldn't include the
> framework assembly in the distribution.
>
>
> I updated the plugin catalog stuff in site/trunk/docs/plugins/geronimo-1.2locally and ran some quick tests of plugin download & install from maven
> repo. I'm ready to commit if/when the 1.2 artifacts are published to
> central.
> Best wishes,
> Paul
>
>
>
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: [vote] Release Geronimo 1.2
Posted by Jason Dillon <ja...@planet57.com>.
Aight, no worries. I still don't fully understand all that plugin
stuff... yet ;-)
--jason
On Apr 5, 2007, at 3:38 PM, Paul McMahan wrote:
> The change I have cued up replaces "1.2-SNAPSHOT" with "1.2" for
> all the catalog entries. So it would break anyone using the
> Geronimo plugin repo from a 1.2-SNAPSHOT server (maybe not a huge
> deal). Also, I've tested the catalog updates by looping http
> requests to repo1.maven.org/maven2 back to my local maven repo. So
> I've made some assumptions about the repo layout that should
> probably be verified.
>
> Best wishes,
> Paul
>
> On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
>
>> Will it hurt anything to commit it now? Or will it break things?
>>
>> --jason
>>
>>
>> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>>
>>>
>>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>>
>>>> I couldn't do much with the framework assembly as it requires a
>>>> plugin repository with 1.2 plugins and AFAIK there is no such
>>>> plugin repository available yet. Will you be making the plugins
>>>> available for 1.2 as you make the release available? If not,
>>>> then perhaps we shouldn't include the framework assembly in the
>>>> distribution.
>>>
>>> I updated the plugin catalog stuff in site/trunk/docs/plugins/
>>> geronimo-1.2 locally and ran some quick tests of plugin download
>>> & install from maven repo. I'm ready to commit if/when the 1.2
>>> artifacts are published to central.
>>>
>>> Best wishes,
>>> Paul
>>>
>>
>
Re: [vote] Release Geronimo 1.2
Posted by Paul McMahan <pa...@gmail.com>.
The change I have cued up replaces "1.2-SNAPSHOT" with "1.2" for all
the catalog entries. So it would break anyone using the Geronimo
plugin repo from a 1.2-SNAPSHOT server (maybe not a huge deal).
Also, I've tested the catalog updates by looping http requests to
repo1.maven.org/maven2 back to my local maven repo. So I've made
some assumptions about the repo layout that should probably be verified.
Best wishes,
Paul
On Apr 5, 2007, at 6:22 PM, Jason Dillon wrote:
> Will it hurt anything to commit it now? Or will it break things?
>
> --jason
>
>
> On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>
>>
>> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>>
>>> I couldn't do much with the framework assembly as it requires a
>>> plugin repository with 1.2 plugins and AFAIK there is no such
>>> plugin repository available yet. Will you be making the plugins
>>> available for 1.2 as you make the release available? If not,
>>> then perhaps we shouldn't include the framework assembly in the
>>> distribution.
>>
>> I updated the plugin catalog stuff in site/trunk/docs/plugins/
>> geronimo-1.2 locally and ran some quick tests of plugin download &
>> install from maven repo. I'm ready to commit if/when the 1.2
>> artifacts are published to central.
>>
>> Best wishes,
>> Paul
>>
>
Re: [vote] Release Geronimo 1.2
Posted by Jason Dillon <ja...@planet57.com>.
Will it hurt anything to commit it now? Or will it break things?
--jason
On Apr 5, 2007, at 3:14 PM, Paul McMahan wrote:
>
> On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
>
>> I couldn't do much with the framework assembly as it requires a
>> plugin repository with 1.2 plugins and AFAIK there is no such
>> plugin repository available yet. Will you be making the plugins
>> available for 1.2 as you make the release available? If not, then
>> perhaps we shouldn't include the framework assembly in the
>> distribution.
>
> I updated the plugin catalog stuff in site/trunk/docs/plugins/
> geronimo-1.2 locally and ran some quick tests of plugin download &
> install from maven repo. I'm ready to commit if/when the 1.2
> artifacts are published to central.
>
> Best wishes,
> Paul
>
Re: [vote] Release Geronimo 1.2
Posted by Paul McMahan <pa...@gmail.com>.
On Apr 5, 2007, at 2:11 PM, Joe Bohn wrote:
> I couldn't do much with the framework assembly as it requires a
> plugin repository with 1.2 plugins and AFAIK there is no such
> plugin repository available yet. Will you be making the plugins
> available for 1.2 as you make the release available? If not, then
> perhaps we shouldn't include the framework assembly in the
> distribution.
I updated the plugin catalog stuff in site/trunk/docs/plugins/
geronimo-1.2 locally and ran some quick tests of plugin download &
install from maven repo. I'm ready to commit if/when the 1.2
artifacts are published to central.
Best wishes,
Paul
Re: [vote] Release Geronimo 1.2
Posted by Joe Bohn <jo...@earthlink.net>.
+1
I downloaded all 5 assemblies, played with the console some on the j2ee
assemblies, deployed an app on each of the jetty/tomcat assemblies and
verified that I could get to the app. I noticed the shutdown errors as
well (actually, they seemed to be slightly different on the different
assemblies). While they are ugly and not very professional they seem
harmless and I think some people might find the release useful ... and
I'm concerned that if we delay to fix these we might not ever release
1.2.
I couldn't do much with the framework assembly as it requires a plugin
repository with 1.2 plugins and AFAIK there is no such plugin repository
available yet. Will you be making the plugins available for 1.2 as you
make the release available? If not, then perhaps we shouldn't include
the framework assembly in the distribution.
Joe
Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are available
> in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>
Re: [discuss] Release Geronimo 1.2
Posted by Hernan Cunico <hc...@gmail.com>.
The release notes are available at http://cwiki.apache.org/GMOxDOC12/release-notes-12txt.html
The "Significant Changes Since the 1.1 Release" section needs to be updated, can you guys chime in with details!?
I just updated the issues section but it will likely require some touch ups later on.
Cheers!
Hernan
Kevan Miller wrote:
>
> Aside from the ongoing technical discussion, I have the following
> comments on the proposed 1.2 binaries and source:
>
> 1) I don't see release notes in the assemblies. Which means no
> instructions on what to with a binary once it has been installed. I
> thought Hernan had generated some release-notes. Not sure what happened
> to them...
> 2) Following files have incorrect source file headers:
>
> modules/geronimo-connector/src/test/java/org/apache/geronimo/connector/mock/ConnectionExtension.java
>
>
> modules/geronimo-connector/src/test/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTrackingCoordinatorProxyTest.java
>
> 3) README.txt in src is way out of date, recommend we delete it...
> 4) STATUS file in src should be removed or updated
> 5) PROPOSAL.txt should be removed
> 6) DISCLAIMER.txt -- ActiveMQ can be removed from the disclaimer --
> it's graduated
>
> Dain,
> I'm willing to fix these issues, just let me know where and when...
>
> 1) and 2) would be enough for me to vote -1.
>
> --kevan
>
>
Re: [discuss] Release Geronimo 1.2
Posted by Dain Sundstrom <da...@iq80.com>.
Can you create JIRAs for these?
On Apr 9, 2007, at 11:03 AM, Kevan Miller wrote:
>
> Aside from the ongoing technical discussion, I have the following
> comments on the proposed 1.2 binaries and source:
>
> 1) I don't see release notes in the assemblies. Which means no
> instructions on what to with a binary once it has been installed. I
> thought Hernan had generated some release-notes. Not sure what
> happened to them...
> 2) Following files have incorrect source file headers:
> modules/geronimo-connector/src/test/java/org/apache/geronimo/
> connector/mock/ConnectionExtension.java
> modules/geronimo-connector/src/test/java/org/apache/geronimo/
> connector/outbound/connectiontracking/
> ConnectionTrackingCoordinatorProxyTest.java
These wouldn't be a critical problem since we don't distribute test
code, but we should fix them now that we have a chance.
-dain
Re: [discuss] Release Geronimo 1.2
Posted by Kevan Miller <ke...@gmail.com>.
Aside from the ongoing technical discussion, I have the following
comments on the proposed 1.2 binaries and source:
1) I don't see release notes in the assemblies. Which means no
instructions on what to with a binary once it has been installed. I
thought Hernan had generated some release-notes. Not sure what
happened to them...
2) Following files have incorrect source file headers:
modules/geronimo-connector/src/test/java/org/apache/geronimo/
connector/mock/ConnectionExtension.java
modules/geronimo-connector/src/test/java/org/apache/geronimo/
connector/outbound/connectiontracking/
ConnectionTrackingCoordinatorProxyTest.java
3) README.txt in src is way out of date, recommend we delete it...
4) STATUS file in src should be removed or updated
5) PROPOSAL.txt should be removed
6) DISCLAIMER.txt -- ActiveMQ can be removed from the disclaimer
-- it's graduated
Dain,
I'm willing to fix these issues, just let me know where and when...
1) and 2) would be enough for me to vote -1.
--kevan
Re: [discuss] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Apr 5, 2007, at 9:44 AM, Hernan Cunico wrote:
> Thanks for putting this together.
> I did some basic testing (did not test security) on the binaries
> and this is what I found so far.
>
> - *geronimo-jetty-j2ee-1.2* takes around 30 sec to start, IFRC it
> used to be under 20 and it also takes longer to shutdown. Tomcat is
> about 10 sec faster for both start and stop.
The timing is about the same on my Mac although I only tested
Tomcat...perhaps djencks can confirm on his Mac with Jetty.
>
> - Both J2EE distros still have the problem of not having accessible
> a newly created embedded Derby DB and still require a Geronimo
> restart.
>
> 09:28:46,296 ERROR [MCFConnectionInterceptor] Error occurred
> creating ManagedConnection for
> org.apache.geronimo.connector.outbound.ConnectionInfo@1cdc394
> javax.resource.spi.ResourceAllocationException: Unable to obtain
> physical connection to jdbc:derby:SomeDB
Hmmm....didn't have any problems deploying and running DayTrader.
>
> - All 4 distros throw this exception on shutdown.
>
> Server shutdown begun
> 09:09:41,296 WARN [BasicLifecycleMonitor] Exception occured while
> notifying listener
> java.lang.NullPointerException
> at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding
> (GBeanBinding.java:159)
> at org.apache.geronimo.gjndi.binding.GBeanBinding
> $GBeanLifecycleListener.stopped(GBeanBinding.java:108)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEven
> t(BasicLifecycleMonitor.java:197)
> at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access
> $500(BasicLifecycleMonitor.java:41)
> at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor
> $RawLifecycleBroadcaster.fireStoppedEvent
> (BasicLifecycleMonitor.java:259)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop
> (GBeanInstanceState.java:359)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:188)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.kernel.config.KernelConfigurationManager
> $ShutdownHook.run(KernelConfigurationManager.java:311)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks
> (BasicKernel.java:668)
> at org.apache.geronimo.kernel.basic.BasicKernel.shutdown
> (BasicKernel.java:645)
> at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:225)
> Server shutdown completed
I see the same thing. Personally it would be great to fix these
items but I don't have bandwidth and I'm not uncomfortable putting
out this release.
>
> Cheers!
> Hernan
>
> Dain Sundstrom wrote:
>> The 1.2 release cut and awaiting your vote! All the files are
>> available in a staging area in my home dir on people.
>> http://people.apache.org/~dain/dist
>> geronimo-1.2-src
>> geronimo-framework-1.2
>> geronimo-jetty-minimal-1.2
>> geronimo-tomcat-minimal-1.2
>> geronimo-jetty-j2ee-1.2
>> geronimo-tomcat-j2ee-1.2
>> Additionally the maven repository with all of the modules,
>> configs, assemblies, etc. is here:
>> http://people.apache.org/~dain/stage/org/apache/geronimo
>> All archives contain LICENSE and NOTICE. Each binary jar is also
>> accompanied by source, javadoc, pom and all are signed, md5-ed,
>> and secure-hashed. Keys file available here:
>> http://people.apache.org/dist/geronimo/KEYS
>> Svn tag is here:
>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>> Here's my +1!
>> -dain
>
Re: [vote] Release Geronimo 1.2
Posted by Davanum Srinivas <da...@gmail.com>.
+0
thanks,
dims
On 4/5/07, Hernan Cunico <hc...@gmail.com> wrote:
> +0 I'm not done with the testing but I would like to see those errors go away.
>
> Cheers!
> Hernan
>
> Dain Sundstrom wrote:
> > So are you saying that you do not want to no release this software until
> > these are fixed?
> >
> > This is a vote thread to determine if we should release this software
> > with it's current warts or run another fix release cycle.
> >
> > -dain
> >
> > On Apr 5, 2007, at 6:44 AM, Hernan Cunico wrote:
> >
> >> Thanks for putting this together.
> >> I did some basic testing (did not test security) on the binaries and
> >> this is what I found so far.
> >>
> >> - *geronimo-jetty-j2ee-1.2* takes around 30 sec to start, IFRC it used
> >> to be under 20 and it also takes longer to shutdown. Tomcat is about
> >> 10 sec faster for both start and stop.
> >>
> >> - Both J2EE distros still have the problem of not having accessible a
> >> newly created embedded Derby DB and still require a Geronimo restart.
> >>
> >> 09:28:46,296 ERROR [MCFConnectionInterceptor] Error occurred
> >> creating ManagedConnection for
> >> org.apache.geronimo.connector.outbound.ConnectionInfo@1cdc394
> >> javax.resource.spi.ResourceAllocationException: Unable to obtain
> >> physical connection to jdbc:derby:SomeDB
> >>
> >> - All 4 distros throw this exception on shutdown.
> >>
> >> Server shutdown begun
> >> 09:09:41,296 WARN [BasicLifecycleMonitor] Exception occured while
> >> notifying listener
> >> java.lang.NullPointerException
> >> at
> >> org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159)
> >>
> >> at
> >> org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
> >>
> >> at
> >> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
> >>
> >> at
> >> org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:311)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668)
> >>
> >> at
> >> org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645)
> >>
> >> at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:225)
> >> Server shutdown completed
> >>
> >> Cheers!
> >> Hernan
> >>
> >> Dain Sundstrom wrote:
> >>> The 1.2 release cut and awaiting your vote! All the files are
> >>> available in a staging area in my home dir on people.
> >>> http://people.apache.org/~dain/dist
> >>> geronimo-1.2-src
> >>> geronimo-framework-1.2
> >>> geronimo-jetty-minimal-1.2
> >>> geronimo-tomcat-minimal-1.2
> >>> geronimo-jetty-j2ee-1.2
> >>> geronimo-tomcat-j2ee-1.2
> >>> Additionally the maven repository with all of the modules, configs,
> >>> assemblies, etc. is here:
> >>> http://people.apache.org/~dain/stage/org/apache/geronimo
> >>> All archives contain LICENSE and NOTICE. Each binary jar is also
> >>> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> >>> secure-hashed. Keys file available here:
> >>> http://people.apache.org/dist/geronimo/KEYS
> >>> Svn tag is here:
> >>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
> >>> Here's my +1!
> >>> -dain
> >
> >
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: [vote] Release Geronimo 1.2
Posted by Hernan Cunico <hc...@gmail.com>.
+0 I'm not done with the testing but I would like to see those errors go away.
Cheers!
Hernan
Dain Sundstrom wrote:
> So are you saying that you do not want to no release this software until
> these are fixed?
>
> This is a vote thread to determine if we should release this software
> with it's current warts or run another fix release cycle.
>
> -dain
>
> On Apr 5, 2007, at 6:44 AM, Hernan Cunico wrote:
>
>> Thanks for putting this together.
>> I did some basic testing (did not test security) on the binaries and
>> this is what I found so far.
>>
>> - *geronimo-jetty-j2ee-1.2* takes around 30 sec to start, IFRC it used
>> to be under 20 and it also takes longer to shutdown. Tomcat is about
>> 10 sec faster for both start and stop.
>>
>> - Both J2EE distros still have the problem of not having accessible a
>> newly created embedded Derby DB and still require a Geronimo restart.
>>
>> 09:28:46,296 ERROR [MCFConnectionInterceptor] Error occurred
>> creating ManagedConnection for
>> org.apache.geronimo.connector.outbound.ConnectionInfo@1cdc394
>> javax.resource.spi.ResourceAllocationException: Unable to obtain
>> physical connection to jdbc:derby:SomeDB
>>
>> - All 4 distros throw this exception on shutdown.
>>
>> Server shutdown begun
>> 09:09:41,296 WARN [BasicLifecycleMonitor] Exception occured while
>> notifying listener
>> java.lang.NullPointerException
>> at
>> org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159)
>>
>> at
>> org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
>>
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
>>
>> at
>> org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:311)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668)
>>
>> at
>> org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645)
>>
>> at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:225)
>> Server shutdown completed
>>
>> Cheers!
>> Hernan
>>
>> Dain Sundstrom wrote:
>>> The 1.2 release cut and awaiting your vote! All the files are
>>> available in a staging area in my home dir on people.
>>> http://people.apache.org/~dain/dist
>>> geronimo-1.2-src
>>> geronimo-framework-1.2
>>> geronimo-jetty-minimal-1.2
>>> geronimo-tomcat-minimal-1.2
>>> geronimo-jetty-j2ee-1.2
>>> geronimo-tomcat-j2ee-1.2
>>> Additionally the maven repository with all of the modules, configs,
>>> assemblies, etc. is here:
>>> http://people.apache.org/~dain/stage/org/apache/geronimo
>>> All archives contain LICENSE and NOTICE. Each binary jar is also
>>> accompanied by source, javadoc, pom and all are signed, md5-ed, and
>>> secure-hashed. Keys file available here:
>>> http://people.apache.org/dist/geronimo/KEYS
>>> Svn tag is here:
>>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>>> Here's my +1!
>>> -dain
>
>
Re: [vote] Release Geronimo 1.2
Posted by Dain Sundstrom <da...@iq80.com>.
So are you saying that you do not want to no release this software
until these are fixed?
This is a vote thread to determine if we should release this software
with it's current warts or run another fix release cycle.
-dain
On Apr 5, 2007, at 6:44 AM, Hernan Cunico wrote:
> Thanks for putting this together.
> I did some basic testing (did not test security) on the binaries
> and this is what I found so far.
>
> - *geronimo-jetty-j2ee-1.2* takes around 30 sec to start, IFRC it
> used to be under 20 and it also takes longer to shutdown. Tomcat is
> about 10 sec faster for both start and stop.
>
> - Both J2EE distros still have the problem of not having accessible
> a newly created embedded Derby DB and still require a Geronimo
> restart.
>
> 09:28:46,296 ERROR [MCFConnectionInterceptor] Error occurred
> creating ManagedConnection for
> org.apache.geronimo.connector.outbound.ConnectionInfo@1cdc394
> javax.resource.spi.ResourceAllocationException: Unable to obtain
> physical connection to jdbc:derby:SomeDB
>
> - All 4 distros throw this exception on shutdown.
>
> Server shutdown begun
> 09:09:41,296 WARN [BasicLifecycleMonitor] Exception occured while
> notifying listener
> java.lang.NullPointerException
> at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding
> (GBeanBinding.java:159)
> at org.apache.geronimo.gjndi.binding.GBeanBinding
> $GBeanLifecycleListener.stopped(GBeanBinding.java:108)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEven
> t(BasicLifecycleMonitor.java:197)
> at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access
> $500(BasicLifecycleMonitor.java:41)
> at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor
> $RawLifecycleBroadcaster.fireStoppedEvent
> (BasicLifecycleMonitor.java:259)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop
> (GBeanInstanceState.java:359)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:188)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
> (GBeanInstanceState.java:180)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
> (GBeanInstance.java:551)
> at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean
> (BasicKernel.java:423)
> at org.apache.geronimo.kernel.config.KernelConfigurationManager
> $ShutdownHook.run(KernelConfigurationManager.java:311)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks
> (BasicKernel.java:668)
> at org.apache.geronimo.kernel.basic.BasicKernel.shutdown
> (BasicKernel.java:645)
> at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:225)
> Server shutdown completed
>
> Cheers!
> Hernan
>
> Dain Sundstrom wrote:
>> The 1.2 release cut and awaiting your vote! All the files are
>> available in a staging area in my home dir on people.
>> http://people.apache.org/~dain/dist
>> geronimo-1.2-src
>> geronimo-framework-1.2
>> geronimo-jetty-minimal-1.2
>> geronimo-tomcat-minimal-1.2
>> geronimo-jetty-j2ee-1.2
>> geronimo-tomcat-j2ee-1.2
>> Additionally the maven repository with all of the modules,
>> configs, assemblies, etc. is here:
>> http://people.apache.org/~dain/stage/org/apache/geronimo
>> All archives contain LICENSE and NOTICE. Each binary jar is also
>> accompanied by source, javadoc, pom and all are signed, md5-ed,
>> and secure-hashed. Keys file available here:
>> http://people.apache.org/dist/geronimo/KEYS
>> Svn tag is here:
>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>> Here's my +1!
>> -dain
Re: [vote] Release Geronimo 1.2
Posted by Hernan Cunico <hc...@gmail.com>.
Thanks for putting this together.
I did some basic testing (did not test security) on the binaries and this is what I found so far.
- *geronimo-jetty-j2ee-1.2* takes around 30 sec to start, IFRC it used to be under 20 and it also takes longer to shutdown. Tomcat is about 10 sec faster for both start and stop.
- Both J2EE distros still have the problem of not having accessible a newly created embedded Derby DB and still require a Geronimo restart.
09:28:46,296 ERROR [MCFConnectionInterceptor] Error occurred creating ManagedConnection for org.apache.geronimo.connector.outbound.ConnectionInfo@1cdc394
javax.resource.spi.ResourceAllocationException: Unable to obtain physical connection to jdbc:derby:SomeDB
- All 4 distros throw this exception on shutdown.
Server shutdown begun
09:09:41,296 WARN [BasicLifecycleMonitor] Exception occured while notifying listener
java.lang.NullPointerException
at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159)
at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423)
at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:311)
at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668)
at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645)
at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:225)
Server shutdown completed
Cheers!
Hernan
Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are available
> in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>
Re: [vote] Release Geronimo 1.2
Posted by Dain Sundstrom <da...@iq80.com>.
I agree and am switching to a -1 also.
At the same time, we can fix the other minor issues people pointed
out and respin.
-dain
On Apr 9, 2007, at 10:51 AM, Matt Hogstrom wrote:
> I'll switch to a -1 given the instabiity of the connection
> manager. I'll help to work on this as its the same code for 2.0.
>
> On Apr 4, 2007, at 8:01 PM, Dain Sundstrom wrote:
>
>> The 1.2 release cut and awaiting your vote! All the files are
>> available in a staging area in my home dir on people.
>>
>> http://people.apache.org/~dain/dist
>> geronimo-1.2-src
>> geronimo-framework-1.2
>> geronimo-jetty-minimal-1.2
>> geronimo-tomcat-minimal-1.2
>> geronimo-jetty-j2ee-1.2
>> geronimo-tomcat-j2ee-1.2
>>
>> Additionally the maven repository with all of the modules,
>> configs, assemblies, etc. is here:
>>
>> http://people.apache.org/~dain/stage/org/apache/geronimo
>>
>> All archives contain LICENSE and NOTICE. Each binary jar is also
>> accompanied by source, javadoc, pom and all are signed, md5-ed,
>> and secure-hashed. Keys file available here:
>>
>> http://people.apache.org/dist/geronimo/KEYS
>>
>> Svn tag is here:
>>
>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>>
>> Here's my +1!
>>
>> -dain
>>
>>
>>
>>
>
Re: [vote] Release Geronimo 1.2
Posted by Kevan Miller <ke...@gmail.com>.
There are some src-related issues, also (posted on discuss thread). I
think they should be resolved, also...
--kevan
On Apr 9, 2007, at 1:51 PM, Matt Hogstrom wrote:
> I'll switch to a -1 given the instabiity of the connection
> manager. I'll help to work on this as its the same code for 2.0.
>
> On Apr 4, 2007, at 8:01 PM, Dain Sundstrom wrote:
>
>> The 1.2 release cut and awaiting your vote! All the files are
>> available in a staging area in my home dir on people.
>>
>> http://people.apache.org/~dain/dist
>> geronimo-1.2-src
>> geronimo-framework-1.2
>> geronimo-jetty-minimal-1.2
>> geronimo-tomcat-minimal-1.2
>> geronimo-jetty-j2ee-1.2
>> geronimo-tomcat-j2ee-1.2
>>
>> Additionally the maven repository with all of the modules,
>> configs, assemblies, etc. is here:
>>
>> http://people.apache.org/~dain/stage/org/apache/geronimo
>>
>> All archives contain LICENSE and NOTICE. Each binary jar is also
>> accompanied by source, javadoc, pom and all are signed, md5-ed,
>> and secure-hashed. Keys file available here:
>>
>> http://people.apache.org/dist/geronimo/KEYS
>>
>> Svn tag is here:
>>
>> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>>
>> Here's my +1!
>>
>> -dain
>>
>>
>>
>>
>
Re: [vote] Release Geronimo 1.2
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'll switch to a -1 given the instabiity of the connection manager.
I'll help to work on this as its the same code for 2.0.
On Apr 4, 2007, at 8:01 PM, Dain Sundstrom wrote:
> The 1.2 release cut and awaiting your vote! All the files are
> available in a staging area in my home dir on people.
>
> http://people.apache.org/~dain/dist
> geronimo-1.2-src
> geronimo-framework-1.2
> geronimo-jetty-minimal-1.2
> geronimo-tomcat-minimal-1.2
> geronimo-jetty-j2ee-1.2
> geronimo-tomcat-j2ee-1.2
>
> Additionally the maven repository with all of the modules, configs,
> assemblies, etc. is here:
>
> http://people.apache.org/~dain/stage/org/apache/geronimo
>
> All archives contain LICENSE and NOTICE. Each binary jar is also
> accompanied by source, javadoc, pom and all are signed, md5-ed, and
> secure-hashed. Keys file available here:
>
> http://people.apache.org/dist/geronimo/KEYS
>
> Svn tag is here:
>
> http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
>
> Here's my +1!
>
> -dain
>
>
>
>