I think it would be good to get the information below into jira issue.
If you could check the jira search below to see if there is another issue that
is similar before creating a new one that would be great.
If there is not another issue that is similar please add a new one.
http://jira.jboss
Would it make sense to create a jira issue for this?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121427#4121427
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121427
___
jb
Unfortunately no - I have been working on interoperability with OC4J, Weblogic,
and websphere.
We will be reviewing priorities and planned tests in the next several weeks. I
will carry on your concern. Rest assured that performance baselines and
benchmarks are among the top of the priorities.
Hi,
Do You have any news on this performance issue? We are currently using Seam 1.2
and have enough performance issues as it is, so an upgrade to Seam 2.0 is out
of the question until we can be sure that the performance is significantly
better than in version 1.2.
Thanks!
View the original po
Thank you so much!! I totally missed this in the docs!!
This did the trick completely!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120690#4120690
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120690
Have you tried @BypassInterceptors on your bean?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120614#4120614
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120614
___
jboss-
"[EMAIL PROTECTED]" wrote : These are surprising results for me as well. I
will review them and compare with our own servers.
|
| I will be adding more tests and comparisons in regards to performance to
the Seam project as time goes on. I appreciate your work on this.
|
Hi Jay,
It wou
Hi lowecg2004,
Thanks for the tip.
Just modified the jpa-no-a4j.ear application adding :
anonymous wrote :
But same results than before (looking at Seam code, debug="false" is the
default value).
So, for a constant throughput of 60tx/s, I have the following results :
cpu used=40%
elapsed(ms)=
The debug mode for Seam would have a significant impact on your stats. Have
you set the debug mode for Seam to false?
In components.xml, try adding:
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111870#4111870
Reply to the post :
http://www.jboss.com/i
Thank you very much for your concern Jay, I'm looking forward for any news you
might have on this subject - whatever it would be (configuration change, code
change or just different results than me).
I'll also be very interested about your performance results between plain jsf
and seam if you m
These are surprising results for me as well. I will review them and compare
with our own servers.
I will be adding more tests and comparisons in regards to performance to the
Seam project as time goes on. I appreciate your work on this.
Thanks,
-Jay
JBoss Seam QE.
View the original post :
So Monday
Hello !
Here is some more information about the load tests we executed.
If you want more information please tell me. Also, if you have an idea on how
we can achieve betters results, I'm interested (of course !).
Otherwise I think you can find some interesting comparative and instr
I'll send more info on Monday then.
Have a good week end and thanks for your help !
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111038#4111038
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4111038
___
"gonzalad" wrote : "svadu" wrote : I wouldn't be surprised if you don't get
very high performance using microcontainer because you're not using full JEE
capabilities of application server.
| I really don't see how MC would explain performance gain between plain jsf
and seam. But I've never use
"svadu" wrote : I wouldn't be surprised if you don't get very high performance
using microcontainer because you're not using full JEE capabilities of
application server.
I really don't see how MC would explain performance gain between plain jsf and
seam. But I've never used MC. Could you explain
"svadu" wrote : There is also somewhat older article from JBoss about Seam
performance, might be interesting as reference information:
http://www.dell.com/downloads/global/power/jbossworld_2006_june_jaffe.pdf
Thanks for this review, I've already looked at it, but read it once more (in
case of..
I wouldn't be surprised if you don't get very high performance using
microcontainer because you're not using full JEE capabilities of application
server. But since you didn't use MC I can't comment on your numbers (I am not a
performance tuning expert).
Was the JSF (without Seam) application a
There is also somewhat older article from JBoss about Seam performance, might
be interesting as reference information:
http://www.dell.com/downloads/global/power/jbossworld_2006_june_jaffe.pdf
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111025#4111025
Rep
Never in fact.
Why ?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111026#4111026
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4111026
___
jboss-user mailing list
jboss-use
Do your tests use JBoss microcontainer in all cases?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111022#4111022
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4111022
___
jb
gus888 - I don't completely understand what you are after, but if you are in an
long running conversation, then if you try to begin another you will get an
exception unless you use join=true. If you always want to rejoin an existing
conversation when you hit @Begin, then just add join=true. Or
"rdewell" wrote : Our primary scope types are EVENT and SESSION. We were early
adopters, and conversations just never worked quite right for us, so we didn't
look back.
Are there any others who made long-running conversations work in production
environment?
We also have a main problem on lon
We strongly recommend scoped deployment, yes.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095324#4095324
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095324
___
jboss-use
I'd like to second that. Getting that "There should only be one Seam phase
listener per application" is not really helpful, since jboss-seam.jar should be
placed in the EAR, not in the WAR. So with more than one SEAM application on
the server you get that message because of the UCL.
Or is Seam
I'm not sure anyone can advise you. You don't specify what hardware you're
running, how much bandwidth you have coming into the server, what you're doing
with the upload. Heck what do you mean by big upload? 1M? 1G? 10G? 1T?
What's the JBoss setup?
There's a lot of questions to be answered b
Look at web-2.0.xsd
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067176#4067176
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067176
___
jboss-user mailing list
jboss-user@
@mgrouch:
How do you cache JNDI lookups?
I only have this in my components.xml. What would I have to add? Thanks!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067174#4067174
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=re
How do I set ajax4jsf forceparser to false with Seam 2.0?
There used to be ajax4jsf filter but not anymore.
I want to disable ajax4jsf tidying up output on each request.
With older Seam version I could do this...
| +
| + Ajax4jsf Filter
| + ajax4jsf
| + org.aj
What are your config values for Ajax4Jsf's 'forceparse' in web.xml and Seam
'debug' in components.xml: ?
I believe that by default, every request is routed through a Tidy filter, even
for non-Ajax pages. forceparse = false will ensure that only Ajax requests go
through the tidy process.
Mak
"mgrouch" wrote : Use factories for stateless objects such as DAOs (so they
are created once and not repeteadly created/destroyed).
|
| ...
| Do not forget to cache JNDI lookups.
|
Again, you can certainly spend time doing this kind of stuff on the off chance
that it will improve per
I think you would want to run your app with a profiler and find out,
empirically, where your app is spending its time. I think most commercial
profilers have trial versions, and there are a variety of ways to do this.
Your app design based on Seam/JSF is no doubt quite different than it was w
Try using one transaction per page load (preferably with one EJB call in case
of CMT). You might have to use wrapper transfer objects (which are considered
not necessary nowadays) to wrap entities of different types.
This made big difference in my case. Do not forget to cache JNDI lookups.
See
And more ideas: Native IO on app server, JRockit JVM. Give JVM higher memory
settings. Use factories for stateless objects such as DAOs (so they are created
once and not repeteadly created/destroyed).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057134#405
And local EJB interfaces vs remote ones to reduce serialization.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057131#4057131
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057131
__
Have you trieed Sun's JSF 1.2? Seam 1.3.0.A is pretty good and 1.3.0 should be
out soon... You also should use facelets instead of JSPs.
Tomahawk immediate="true" helps a bit too on forms where you do not need
validation. Hibernate caching should be used. Reduce number of complicated
EL expressio
Thanks for your reply. I am using server side states saving, and we don't have
hashmap lookup in our pages.
We can't migrate to MyFaces 1.1.5 and Tomahawk 1.1.6 due to compatibility
problem with seam 1.2.1. Also, MyFaces 1.1.5 doesn't work well with Seam 1.3.
So basically we can't change our en
And in your case you should migrate to MyFaces 1.1.5 and Tomahawk 1.1.6.
MyFaces 1.1.3 is too broken anyway to be used in production.
It would be interesting to compare Myfaces 1.1.5 performance
vs Sun's JSF 1.2 (with server side state for both) and see who wins...
View the original post :
h
Another thing:
JSF doesn't (in base components) let you to define a variable on a page.
So people quite often would write something like
#{hashMapBean[key].prop}
in many places on the page, which in fact leads to looking up hashMap many
times + using reflection to access property.
JSF also has
Can you change JSF setting to 'server' side state saving (in web.xml) and try
the tests again? With myfaces and these suggestions
http://wiki.apache.org/myfaces/Performance
it had dramatic effect.
I haven't tried with Sun's JSF 1.2, but client side state saving should have
negative impact on
Interesting, thanks for the feedback! :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036886#4036886
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036886
___
jboss-user ma
Nice to see Seam working well :) Made an interesting read!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034294#4034294
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034294
We're using it on light test-level volume now to run about 40k / month in
sales. This includes the management back-end to setup products / manage
customers, etc.
Performance is fine, but then we aren't using some of the potentially
heavyweight Seam features like conversations. Our primary s
On the second question, it almost never makes sense to have EJBs on a separate
tier from the web application.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002067#4002067
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&
43 matches
Mail list logo
