[EMAIL PROTECTED] wrote : It should not happen. Do you see any other errors
during first deployment?
As a matter of fact, I do. If I convert just a couple of beans to the new
container configuration, I get:13:20:36,526 ERROR [EntityContainer] Starting
failed
I did try -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, and -XX:+UseParallelGC,
the first two both by themselves and together. -XX:+UseParNewGC shaved maybe 5
seconds off the test run time. -XX:+UseConcMarkSweepGC actually made my test
about 10 seconds slower, and -XX:+UseParNewGC didn't make much
anonymous wrote : Have you tried 'cmp2.x jdbc2 pm' container?
Just did, and it seems to not like redeploying my EJBs -- do I have to do
something special to get redeployment to work? It spews exceptions like
org.jboss.deployment.DeploymentException: Failed to register table cache for
IP_AUC; -
anonymous wrote : Have a look at
| http://www-106.ibm.com/developerworks/java/library/j-jtp11253/
| and try to setup your JVM parameters more properly.
Thanks for that pointer. I've tried fiddling with different sizes for different
parts of the heap and switching garbage collectors. I can
On the test run that produced those numbers, the VM arguments I passed into
run.sh were:
-XX:MaxNewSize=768m -XX:SurvivorRatio=8 -Xms1536m -Xmx1536m -verbose:gc
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails
I had tried setting MinNewSize as well but it didn't seem to make any big
difference in
Thanks, that seems to have done the trick!
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3857681#3857681
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3857681
---
SF
I've been evaluating JBoss 4.0.1RC2 and WebLogic 8.1SP2 to host an online
auction application. I'm now far enough along to have a few numbers, and I
thought others might be interested in the effects of different tuning
operations.
The test server setup is the same for both: a BigIP load
No joy. I checked out the latest sources from CVS just now, and I still get the
same exception:
java.lang.NullPointerException
at
org.jboss.resource.adapter.jdbc.PreparedStatementCache.ageOut(PreparedStatementCache.java:37)
at
I have a stress test tool that does lots of JSP fetches without retaining any
cookies between requests. The container therefore is creating a new session for
each request (which is the expected behavior) and my JSP code is setting a few
session attributes when it sees it's dealing with a new
Thanks! That seems to have done the trick.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3857636#3857636
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3857636
---
SF
I should add that switching to asynchronous instant replication, or to
interval-based replication, does not seem to help.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3857645#3857645
Reply to the post :
I'm still seeing this problem in 4.0.1RC2, which was just released (over a
month after the bug in question was marked closed, so I assume it ought to
include the fix.)
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3857448#3857448
Reply to the post :
I started seeing the same problem under 4.0.1RC1 when I turned on the prepared
statement cache. My OS is Solaris 9, JVM is Sun's 1.4.2_06 on a dual-processor
SPARC server talking to an Oracle 8i database.
So I guess we've established that it's not OS-specific, it's not
database-specific, and
Has anyone gotten the search function on this message board to do and queries
(search for threads containing X and Y)? It seems like it turns the and into
or.
For example, search for InitialContext and you get 2433 matches. Search for
InitialContext and EJB and you get 17258 matches -- adding
Just tried that, no change in behavior. The machines can definitely ping each
other by name.
I wonder... Are you sure you're actually getting sticky sessions? If you reload
a JSP or servlet a bunch of times, do the requests only ever go to one of the
app servers? And when you clear the
Got it!
It turns out there's one other thing you have to change. It's not documented in
the 3.x clustering book or the using mod_jk with JBoss wiki page, but if you
dig around in the wiki enough, you come across a link to New JBoss3.2.6 Tomcat
session replication which has a brief mention of
That seems to work. Thanks. Had no idea it was case-sensitive.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3855069#3855069
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3855069
I have a cluster of two JBoss 4.0.1RC1 servers sitting behind an Apache 2
server running mod_jk2. The Apache server is doing load balancing and failover,
but so far I have been completely unable to get session stickiness to work. The
JSESSIONID cookie never includes the jvmRoute value.
I've
Thanks for the suggestion. I modified my workers2.properties to look like
yours, but still no stickiness. Apache still happily talks to both of the app
servers, but if I open a browser, go to one of my JSPs, and repeatedly reload
the page, I see the requests going to both app servers instead of
Oh, I should add that I also tried replacing the hostnames with the IP
addresses in the channel definitions, no effect that I can tell.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3854950#3854950
Reply to the post :
I'm looking to set up a 4.0 cluster, but there seems to be zero documentation on the
subject. How applicable is the 3.x clustering documentation to 4.0? If everything
stayed pretty much the same, then I'll happily buy the book, but if there were a lot
of changes, I'd just be wasting money.
I'm having a very similar problem, probably the same root cause: I have an MBean that
talks to a session bean that lives in an exploded ear. It worked fine in 3.x but in
4.0.0 when it tries to do the JNDI lookup on the local home interface, I get
javax.naming.CommunicationException [Root
22 matches
Mail list logo
