Hi,
I'm trying to upgrade from 3.0.6 to 3.2.0RC3 and I'm having problems getting my EAR to deploy.
Inside my exploded EAR there's a couple of webapps, and an ejb directory with about 20 ejb
jars. Not all of the ejbs are currently in use (we're working on some major surgery to our
application
Having just upgraded I found that 3.2.0RC3 is configured to use the JDBC persistence
manager for JMS by default. 3.0.x was configured to use the file persistence manager by
default. The JDBC persistence relies on the Default hsqldb datasource.
Because I don't need to use the database
Hi, I've got an EAR with 16 deployment units and a large jar containing shared classes,
and when I redeploy the EAR JBoss keeps using more disk space.
When the server starts I see 16 copies of my shared lib under
tmp/deploy/server/ccsadm/deploy/my.ear/libs/shared.jar/, each numbered. When I
I'm getting this CMR error when I load test our system:
java.lang.IllegalStateException: The iterator of a CMR collection may only be used within
the transction in which it was created
at
org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet$1.verifyIteratorIsValid(RelationSet.java:309)
I've just tried it and RC4 has the same problem. We're using normal jbosscmp container.
Andrew
Simone Milani wrote:
Hi,
I had the same promlem when I was using RC3. Try to move to RC4. What
container are you using?
Simone
---
This
OK, here's a test case that recreates the problem for me.
I've attached test.jar which is the ejb-jar and also includes the test case class. Also
attached is test-src.jar which has the source code for the EJBs and the test. I'm afraid
I've been hacking around existing build scripts to create
it.
alex
Monday, March 31, 2003, 12:37:32 PM, Andrew May wrote:
AM OK, here's a test case that recreates the problem for me.
AM I've attached test.jar which is the ejb-jar and also includes the test case class. Also
AM attached is test-src.jar which has the source code for the EJBs and the test
trying your test, do you have a script to populate the tables and
the parameters for the CMRTestClass?
Thanks
Simone
- Original Message -
From: Andrew May [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 31, 2003 2:46 PM
Subject: Re: [JBoss-user] CMR Error under load
I don't see
I've just built RC5 from CVS and I still get the CMR problem.
Release ID: JBoss [WonderLand] 3.2.0RC5 (build: CVSTag=Branch_3_2 date=200304010938)
Alex Loubyansky wrote:
with fresh 3.2.0RC5 from CVS?
alex
---
This SF.net email is
- Original Message -
SM From: Andrew May [EMAIL PROTECTED]
SM To: [EMAIL PROTECTED]
SM Sent: Tuesday, April 01, 2003 8:40 AM
SM Subject: Re: [JBoss-user] CMR Error under load
Simone,
I manually inserted a couple of records. e.g.:
INSERT INTO Parent VALUES ('test1');
INSERT INTO Child (id
in the thread Alex wrote that I'm not alone in complaining about this. Is there an
existing bug report for this problem that I should add the details of my test case to, or
should I file a new bug?
Andrew
Andrew May wrote:
In our application which is causing the problem we have a session
facade. I
CMP implementation relies on Transactions to ensure
thread safety?
Andrew
Dain Sundstrom wrote:
I think the message is remove the read-only tags and you will not get
the errors.
-dain
On Thursday, April 3, 2003, at 03:03 AM, Andrew May wrote:
My test case fails on 3.0.3 so it's not just
Hi, I'm trying to use an XA datasource with Oracle 8.1.7 for the first time and I'm
getting this error:
14:56:23,707 WARN [TransactionImpl] XAException: tx=TransactionImpl:XidImpl
[FormatId=257, GlobalId=cleaver.ingenta.com//3, BranchQual=] errorCode=XAER_NOTA
oracle.jdbc.xa.OracleXAException
Hi,
We've just release a production service using JBoss 3.2.1 on Solaris with Sun's 1.4.2 JVM,
and we're seeing a deadlock on the AbstractInstanceCache for one of our stateful session
beans that's used heavily.
Over a period of time more and more threads become locked trying to insert or get
likely to cause
deadlocks.
Andrew
Bill Burke wrote:
Ok, I found the deadlock scenarioTrying to figure out the fix. For now,
set the overager-period to 0 to turn off the overager thread.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andrew May
Sent
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Andrew May wrote:
Thanks,
We've changed the config for stateful session beans, unfortunately it
doesn't seem to like that:
Caused by: org.jboss.deployment.DeploymentException: Overager period
can't be = 0
again,
Andrew
Bill Burke wrote:
reget the patch. I screwed up the file with my first patch, but thanks to
Scott's catch it is fixed now.
again,
LRUEnterpriseContextCachePolicy.java
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andrew May
Sent
Our production application has on several times run out of connections from a pool and
we've had to restart the server to reset the pool.
We have a pool of 100 Oracle connections used for BMP entity beans and calls to the
database from Session beans via Data Access Objects:
There's an SQLException thrown when calling getConnection() on the Datasource retrieved
from JNDI. This gets wrapped in an application exception (ISISConnectionException) with
the message ISISDatabaseConnection: Unable to create connection to ISIS Database, but
the nested SQLException is being
for rollback)
at
org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:106)
I've made the changes so that it's not trying to get 20 connections, but it has made one
connection permenantly unavailable.
-Andrew
Andrew May wrote:
There's an SQLException thrown
Thanks, yes I figured it out in the end, and actually I've removed transactions altogether
for the beans involved because everything is read-only and there's no worries about
inconsistent state.
I think there's probably a bug in the Connection Manager, so that when
b) is there a
better searcher for this mailinglist? (hmmm, maybe google with site:)
Try http://www.mail-archive.com/[EMAIL PROTECTED]/
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce,
Edit conf/log4j.xml and your changes will be picked up after a short delay (or you can use
the reconfigure method in the MBean to force it to re-read the configuration file).
-Andrew
Peter Luttrell wrote:
Is there any way to change the log level for the server.log at runtime?
I've looked at
I'm having a problem trying to user sync-on-commit-only and cascade-delete with JBoss
3.2.1 (Sun JDK1.4.2, Solaris).
We've got a number of related entities like this:
LOGIN---IDENTITY
| |
LOGINPROPERTIES IDENTITYPROPERTIES
login-identity,
Alex,
Thanks for your reply - my answers in-lined:
-Andrew
Alexey Loubyansky wrote:
Hello, Andrew.
my comments in-lined.
Andrew May wrote:
I'm having a problem trying to user sync-on-commit-only and
cascade-delete with JBoss 3.2.1 (Sun JDK1.4.2, Solaris).
We've got a number of related
concurrent access to the beans when I'm attempting these deletes.
-Andrew
Alexey Loubyansky wrote:
Are there other beans involved in the tx? Something, causes
synchronization. If all the CMP2 beans have sync-on-commit-only=true,
then it shouldn't happen.
alex
Andrew May wrote:
Alex,
Thanks for your
I've only played around with clusters, so I could be wrong, but I think you need to access
HA-JNDI directly on the port it's bound to. If the object cannot be found in HA-JNDI it
will look in the local JNDI.
From the clustering docs:
When a remote client does a lookup through HA-JNDI, HA-JNDI
Hi,
We've just upgraded to 3.2.2 from 3.2.1 and we're having a problem with one our JDBC
connection pools.
We're using a BASIS bibliographic database that only allows you to query the database if
the JDBC connection is read-only. After we get a connection from a Datasource we're
calling
This has been fixed.
You should also notice that this performs better in 3.2.3RC1
compared with 3.2.1 if you always do readonly on the connection.
ReadOnly is now set lazily, so it will only pass the request to the db
the first time. After that it will remain as readonly until you
don't
This is the diff (fairly trivial):
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/WrappedConnection.jpp?r1=1.1.2.8r2=1.1.2.9
Thanks, that does the trick. Once again I can search obscure bibliographic databases :)
-Andrew
We have this problem when users double click on links. The way we've got around it is to
synchronize access the the stateful bean in the servlet layer by synchronizing on the
Remote interface object. This at least serializes the requests and prevents concurrent
access (which causes the bean to
Apache 1.3.x can have a maximum of something like 255 processes servicing requests. If
there are more active apache processes than Jetty threads you can get this problem. We use
mod_jk to connect from Apache 1.3 to Jetty, and have set the Jetty thread count to 256.
Note that it's still possible
We migrated from WebLogic 5 to JBoss and changed our startup classes into Standard MBeans.
It's possible to do many of the same kind of things start up classes allow you to do, such
as creating/manipulating connection pools, all via JMX.
If you implement a start() method in your MBean it will
If you use the Prefix deployment sorter and add a numeric prefix to your deployment file
(e.g. user-service.xml - 99.user-service.xml) it will be processed after all the other
files in deploy. Everything else will be deployed in the same order as before.
Enable this by editing
I don't believe that there's any way to change the connection url via the Datasource -
this will only allow you to create connections from the preconfigured connection pool.
If you have multiple databases you can create multiple connection pools and bind them as
seperate datasources (e.g.
We use a very similar mod_jk set-up and it seems to work. We don't have the cachesize
setting though (what does that do?), and we have both lbfactor's set to 10 (for no
particular reason - I'd expect 1 on both to behave the same).
What we did find when we were testing this is by hand is that it
I'd agree - and I'd probably say that forcing garbage collection is likely to have an
adverse effect on performance as the JVM has a much better idea of when to GC than anyone
else does.
With Sun's 1.4 JVM there are now several types of Garbage Collector available, and you may
find some are
The initial lookup will be on a fixed port (e.g. 1099 by default) - unless otherwise
configured the RMI communication will then be on an anonymous (i.e. random) free port. So
if you've only got 1099 open between the servers then the lookup will work but further RMI
communication will then fail.
38 matches
Mail list logo
