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.
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
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
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.
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
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
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
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:
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
Only a very light load from a few browsers. One thing to try is to
increase the number of SLSBs in the pool.
Can you add
session
ejb-nameTradeJDBC/ejb-name
jndi-nameejb/TradeJDBC/jndi-name
cache-size100/cache-size
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.
external-rarorg.apache.geronimo.modules
/ge-activemq-rar/1.2/rar/external-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
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
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
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
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
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
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
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 (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
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
Please post comments about the release here... the vote thread should
simply be +1 / 0 / -1
Thanks
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
Hello all,
I created a JIRA and attached a patch to correct the NPE during
shutdown: Jira 3068.
Jay
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
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
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
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
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 :)
I did my test on a linux system though - maybe this is windows related (?)
Jay
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
31 matches
Mail list logo
