David .et .al:
re: Geronimo "issues"
I still have an unresolved "issue" reading a database. Have no idea if
it's Geronimo, Postgres or something in between or beyond. Granted, it
is a big DB with over 14Million records, but Webtools Entity Reference &
XML exports don't work. I run out of memory, regardless of how much
memory I allocate during system startup. I do know that simple Postgres
psql and pgAdmin can read this database and return from a simple "select
*" query of the (single) table in question.
I agree that this isn't a show stopper and does not need to be resolved
for the release, but...is there even a next step in tracking down issues
such as this? Is there anything else I can do to help isolate and
perhaps correct this problem?
Ruth
David E Jones wrote:
Si Chen wrote:
Hi everybody -
I'm really glad we will be doing a release for OFBIZ again. Here are
a things I would really like to see -
[snip]
3. Separately, there are some production-readiness issues which we
should address prior to a release. For example, there was a
typecasting issue for the minilang field-to-field and a PostgreSQL
bytea/oid issue that conflicted with Derby which were never
satisfactorily resolved. I think if we're going to put out a release
and tell our users "this is ready for production use", we should
address those.
4. Also, has the new Geronimo transaction manager been fully
tested? Are the reports of transaction time out issues real?
With the branch process I mentioned in the other email these issues
don't matter so much.
Yes, we want to have something as close to production-ready as
possible, but OFBiz is a big system that supports a really wide
variety of lower lever software to interact with, so there is no way
we can guarantee (unless someone has a bunch of money socked away that
they want to dedicate to a testing lab...) that OFBiz will work OOTB
with all combinations of infrastructure software without subtle
configuration and/or code changes specific to a circumstance.
So, while these two issues are worth keeping an eye on and fixing when
we can, I don't think either is a show-stopper for a release, even a
"production stable" release.
For both of these it may be that those who are able to fix such things
don't have the resources to do so now, but any reasonable size
deployment team usually has people around who can. Also, such things
are often easier to fix for a specific circumstance than something
that is meant to work in a wide variety of cases, which is the case
with the Postgres issue. With a little creativity and experience it is
possible to fix in a very widely applicable way any such issue and not
have any problems with Derby or Postgres, but with no resources to do
so... the best we can do is get a release out and attract more
resources to the community...
On the Geronimo issue: I still haven't seen reports of anything that
seems to be a core issue with Geronimo. People report errors all the
time that are caused by things like timeouts and such or a lower level
error that causes rollback-only to be set and these manifest higher up
as transaction errors, but the details are in the logs. So far I
haven't seen any clear definition of a problem with Geronimo. That
doesn't mean there isn't one, it just means that from what I've seen
on the lists it hasn't been isolated yet (ie seen by someone who can
recognize it for what it is and distinguish between a real Geronimo
problem and a simple timeout or other error that caused the
transaction error).
-David
