Re: [discuss] Release Geronimo 1.2

[Hernan Cunico]

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

[Dain Sundstrom]

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

[Kevan Miller]

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

[Matt Hogstrom]

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

[Jay D. McHugh]

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

[Matt Hogstrom]

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

[David Jencks]

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* <[EMAIL PROTECTED]  
> 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

Re: [discuss] Release Geronimo 1.2

[Matt Hogstrom]

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* <[EMAIL PROTECTED]  
> 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 

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

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* <[EMAIL PROTECTED] 
> 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* < [EMAIL 

Re: [discuss] Release Geronimo 1.2

[David Jencks]

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* <[EMAIL PROTECTED]  
> 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* < [EMAIL PROTECTED]

> >>

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)
>>
>>
 

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

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* <[EMAIL PROTECTED] 
> 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* < [EMAIL PROTECTED]

> >>
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* < [EMAIL PROTECTED]

>> >> 
wrote:

>>
>> Only a very light load from a few browsers.  One thing
 

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

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* <[EMAIL PROTECTED] 
> 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* < [EMAIL PROTECTED]

> >>
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* < [EMAIL PROTECTED]

>> >> 
wrote:

>>
>> Only a very light load from a few browsers.  One thing

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

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* <[EMAIL PROTECTED] 
> 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* < [EMAIL PROTECTED]

> >>
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* < [EMAIL PROTECTED]

>> >> 
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
>>
>> 
>>

Re: [discuss] Release Geronimo 1.2

[David Jencks]

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* <[EMAIL PROTECTED]  
> 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* < [EMAIL PROTECTED]

> >>

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* < [EMAIL PROTECTED]

>> >>  
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
>>
>> 
>> TradeJDBC
>> ejb/TradeJDBCname>

>> 100
>> 
>>
>> 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, 

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

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* <[EMAIL PROTECTED] 
> 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* < [EMAIL PROTECTED]

> >>
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* < [EMAIL PROTECTED]

>> >> 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
>>
>> 
>> TradeJDBC
>> ejb/TradeJDBC
>> 100
>> 
>>
>> 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)
   

Re: [discuss] Release Geronimo 1.2

[Christopher Blythe]

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 <[EMAIL PROTECTED]> 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* < [EMAIL PROTECTED]
> > 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* < [EMAIL PROTECTED]
>> > 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
>>
>> 
>> TradeJDBC
>> ejb/TradeJDBC
>> 100
>> 
>>
>> 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
()
>>> 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
>>>

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

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* < [EMAIL PROTECTED] 
> 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* < [EMAIL PROTECTED]
> 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 



TradeJDBC
ejb/TradeJDBC
100


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()
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()
at
org.apache.openejb.NoConnectionEnlistingInterceptor.invoke
(NoConnectionEnlistingInterceptor.java:70)
at

org.apache.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:35)
at

Re: [discuss] Release Geronimo 1.2

[Christopher Blythe]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
> 
> TradeJDBC
> ejb/TradeJDBC
> 100
> 
>
> 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
> ()
> 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
> ()
> 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()
>
> 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 

Re: [discuss] Release Geronimo 1.2

[David Jencks]

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 <[EMAIL PROTECTED]> 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


TradeJDBC
ejb/TradeJDBC
100


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()

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()
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()

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$ 

Re: [discuss] Release Geronimo 1.2

[Christopher Blythe]

org.apache.geronimo.modules
/ge-activemq-rar/1.2/rar


On 4/6/07, Jason Dillon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
> 
> TradeJDBC
> ejb/TradeJDBC
> 100
> 
>
> 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
> ()
> 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
> ()
> 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()
>
> 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()
> at org.apache.openejb.AbstractEjbDeployment.invoke(
> AbstractEjbDeployment.java:195)
> at 

Re: [discuss] Release Geronimo 1.2

[Jason Dillon]

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 <[EMAIL PROTECTED]> 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


TradeJDBC
ejb/TradeJDBC
100


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()

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()
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()

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 ()
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 ()
at 

Re: [discuss] Release Geronimo 1.2

[Matt Hogstrom]

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


TradeJDBC
ejb/TradeJDBC
100


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()

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()
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()

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 ()
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 ()
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 

Re: [discuss] Release Geronimo 1.2

[Anita Kulshreshtha]

   I also ended up using the same application. Here are my
observations:
1. The Pool deployment using "deploy New" after minor modification to
InventoryPool.xml worked. The App worked fine.
2. When the pool was deployed using DBPool wizard, the app deployed
fine, accessing /inventory threw the exception reported earlier. The
plan generated by the wizard did not have a dependency on
system-database. I had to add dependency on system-database to the
generated plan to  get it to work correctly. 
   Does anyone know why system-database has become unavailable
recently?
3.  The fix for shutdown problem was applied to the trunk:
http://svn.apache.org/viewvc?view=rev&rev=488106
  It must be applied to 1.2 as well.
  I believe that these problems can be fixed easily. Unless I have
overlooked something I think we can release 1.2. 
   
Thanks
Anita
   
--- "Jay D. McHugh" <[EMAIL PROTECTED]> wrote:

> I went through the 'sample database access sample application' on the
> 
> wiki and everything worked fine.  I was able to use all of the
> functions 
> (few though they are) without any errors.
> 
> Jay
> 
> Hernan Cunico wrote:
> > Jay D. McHugh wrote:
> >> Laziness rocks!  That's why I didn't include the link :)
> >>
> >> https://issues.apache.org/jira/browse/GERONIMO-3068
> >>
> >> Also, I was able to create a new database through the web console
> and 
> >> add a table to it with no problems.  Hernan, what did you do that 
> >> caused the error?
> >
> > You can create a DB and populate some initial data right away from
> the 
> > console, you can even define a datasource and get a successful 
> > connection test. But when your application tries to access that DB
> you 
> > get the error I'm talking about. This is not a "new" error and the 
> > only workaround so far is to restart Geronimo. AFAICT this is a
> Derby 
> > issue and a pretty consistent one, reproducing it should be very
> easy, 
> > FWIW I'm using Windows XP and java version "1.5.0_11"
> >
> > Cheers!
> > Hernan
> >
> >>
> >> Jay
> >>
> >> Jason Dillon wrote:
> >>> I'm super lazy, can you (and everyone else) provide the full URL
> to 
> >>> the issue in the future?
> >>>
> >>> --jason
> >>>
> >>>
> >>> On Apr 5, 2007, at 1:18 PM, Jay D. McHugh wrote:
> >>>
>  Hello all,
> 
>  I created a JIRA and attached a patch to correct the NPE during 
>  shutdown: Jira 3068.
> 
>  Jay
> 
> >>>
> >>>
> >>>
> >>> .
> >>>
> >>
> >
> >
> >
> 



 

Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

I did my test on a linux system though - maybe this is windows related (?)

Jay

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

I went through the 'sample database access sample application' on the 
wiki and everything worked fine.  I was able to use all of the functions 
(few though they are) without any errors.


Jay

Hernan Cunico wrote:

Jay D. McHugh wrote:

Laziness rocks!  That's why I didn't include the link :)

https://issues.apache.org/jira/browse/GERONIMO-3068

Also, I was able to create a new database through the web console and 
add a table to it with no problems.  Hernan, what did you do that 
caused the error?


You can create a DB and populate some initial data right away from the 
console, you can even define a datasource and get a successful 
connection test. But when your application tries to access that DB you 
get the error I'm talking about. This is not a "new" error and the 
only workaround so far is to restart Geronimo. AFAICT this is a Derby 
issue and a pretty consistent one, reproducing it should be very easy, 
FWIW I'm using Windows XP and java version "1.5.0_11"


Cheers!
Hernan



Jay

Jason Dillon wrote:
I'm super lazy, can you (and everyone else) provide the full URL to 
the issue in the future?


--jason


On Apr 5, 2007, at 1:18 PM, Jay D. McHugh wrote:


Hello all,

I created a JIRA and attached a patch to correct the NPE during 
shutdown: Jira 3068.


Jay





.

Re: [discuss] Release Geronimo 1.2

[Hernan Cunico]

Jay D. McHugh wrote:

Laziness rocks!  That's why I didn't include the link :)

https://issues.apache.org/jira/browse/GERONIMO-3068

Also, I was able to create a new database through the web console and 
add a table to it with no problems.  Hernan, what did you do that caused 
the error?


You can create a DB and populate some initial data right away from the console, you can even define 
a datasource and get a successful connection test. But when your application tries to access that 
DB you get the error I'm talking about. This is not a "new" error and the only workaround 
so far is to restart Geronimo. AFAICT this is a Derby issue and a pretty consistent one, 
reproducing it should be very easy, FWIW I'm using Windows XP and java version "1.5.0_11"

Cheers!
Hernan



Jay

Jason Dillon wrote:
I'm super lazy, can you (and everyone else) provide the full URL to 
the issue in the future?


--jason


On Apr 5, 2007, at 1:18 PM, Jay D. McHugh wrote:


Hello all,

I created a JIRA and attached a patch to correct the NPE during 
shutdown: Jira 3068.


Jay





.

Re: [discuss] Release Geronimo 1.2

[Matt Hogstrom]

Laziness may be adequate for some but I'm wy past that ...

http://www.despair.com/proc24x30pri.html


On Apr 5, 2007, at 4:35 PM, Jay D. McHugh wrote:


Laziness rocks!  That's why I didn't include the link :)

https://issues.apache.org/jira/browse/GERONIMO-3068

Also, I was able to create a new database through the web console  
and add a table to it with no problems.  Hernan, what did you do  
that caused the error?


Jay

Jason Dillon wrote:
I'm super lazy, can you (and everyone else) provide the full URL  
to the issue in the future?


--jason


On Apr 5, 2007, at 1:18 PM, Jay D. McHugh wrote:


Hello all,

I created a JIRA and attached a patch to correct the NPE during  
shutdown: Jira 3068.


Jay





.

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

Laziness rocks!  That's why I didn't include the link :)

https://issues.apache.org/jira/browse/GERONIMO-3068

Also, I was able to create a new database through the web console and 
add a table to it with no problems.  Hernan, what did you do that caused 
the error?


Jay

Jason Dillon wrote:
I'm super lazy, can you (and everyone else) provide the full URL to 
the issue in the future?


--jason


On Apr 5, 2007, at 1:18 PM, Jay D. McHugh wrote:


Hello all,

I created a JIRA and attached a patch to correct the NPE during 
shutdown: Jira 3068.


Jay





.

Re: [discuss] Release Geronimo 1.2

[Jason Dillon]

I'm super lazy, can you (and everyone else) provide the full URL to  
the issue in the future?


--jason


On Apr 5, 2007, at 1:18 PM, Jay D. McHugh wrote:


Hello all,

I created a JIRA and attached a patch to correct the NPE during  
shutdown: Jira 3068.


Jay

Re: [discuss] Release Geronimo 1.2

[Jay D. McHugh]

Hello all,

I created a JIRA and attached a patch to correct the NPE during 
shutdown: Jira 3068.


Jay

Re: [discuss] Release Geronimo 1.2

[Matt Hogstrom]

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  
[EMAIL PROTECTED]
	javax.resource.spi.ResourceAllocationException: Unable to obtain  
physical connection to jdbc:derby:SomeDB


Hmmmdidn'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