[Remoting] - New blocking mode for pul callbacks
by ron.sigalï¼ jboss.com
Remoting has a new callback polling mode, in response to the forum thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990104#3990104 .
In the original mode, now known as "nonblocking" mode, org.jboss.remoting.Client.getCallbacks() makes an invocation on the server and returns all waiting callbacks. If there are no callbacks to be retrieved, it returns an empty list. This call may be made directly from the application, in the manner of pull callbacks, or it can be made from an instance of org.jboss.remoting.callback.CallbackPoller, which simulates push callbacks by pulling callbacks from the server and then pushing them to an org.jboss.remoting.callback.InvokerCallbackHandler. See Section 5.6 "Callbacks" in the Remoting Guide (http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#section-callbacks ) for more information.
The problem with nonblocking mode is latency. For example, if CallbackPoller is used, the default behavior is to poll for callbacks every five seconds. In the new "blocking" mode, on the other hand, Client.getCallbacks() will either
1. return all waiting callbacks, if there are any, or
2. if there are no waiting callbacks, block on the server side and wait until a callback is created or until the timeout period elapses.
In other words, in blocking mode, a callback will be returned soon after it is created
The default behavior is to use nonblocking mode, to avoid behavioral changes without explicit action. To switch to blocking mode, the key org.jboss.remoting.ServerInvoker.BLOCKING_MODE (actual value "blockingMode") needs to be added to the appropriate configuration map, as explained below, with the value ServerInvoker.BLOCKING (actual value "blocking").
To accomodate pull callbacks, a new method
| public List getCallbacks(InvokerCallbackHandler callbackHandler, Map metadata) throws Throwable;
|
has been added to the Client class, and the configuration information can be passed in the metadata map. If CallbackPoller is used, then one of the methods from the Client class
| public void addListener(InvokerCallbackHandler callbackhandler, Map metadata) throws Throwable;
|
| public void addListener(InvokerCallbackHandler callbackhandler, Map metadata,
| Object callbackHandlerObject) throws Throwable;
|
| public void addListener(InvokerCallbackHandler callbackhandler, Map metadata,
| Object callbackHandlerObject, boolean serverToClient) throws Throwable;
|
may be used, with the configuration information passed in the metadata map.
A couple of additional configuration parameters are available, which are passed the same way as the blocking mode.
1. ServerInvoker.BLOCKING_TIMEOUT (actual value "blockingTimeout") determines how long the Client.getCallbacks() will block on the server side, waiting for a callback to be created, before timing out and returning an empty list. The default value is 5000 ms.
2. CallbackPoller.MAX_ERROR_COUNT (actual value "maxErrorCount") determines how many errors CallbackPoller will sustain before it stops polling and shuts itself down. This parameter applies to both blocking and nonblocking polling. The default value is 5
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057085#4057085
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057085
18Â years, 10Â months
[JBoss Seam] - Re: [1.3 CVS]Tomcat users getting the shaft?
by dsmithï¼ nesmi.com
"gavin.king(a)jboss.com" wrote :
| Please test this out for me, since I did it especially for you, and I need to release 1.3 in a couple of days. Thanks.
Thank you Gavin, for working on this.
Using
| <transaction:entity-transaction entityManager="#{myEntityManager}"/>
|
There is a circular dependency between EntityManager and EntityTransaction so I get one big nasty stack trace
| ManagedPersistenceContext
| ----
| @Unwrap
| public EntityManager getEntityManager() throws NamingException, SystemException
| {
| if (entityManager==null) initEntityManager();
|
| //join the transaction
| if ( !synchronizationRegistered && !Lifecycle.isDestroying() && Transaction.instance().isActive() )
|
and
| EntityTransaction
| ------
| @Unwrap
| @Override
| public UserTransaction getTransaction() throws NamingException
| {
| EntityManager em = entityManager.getValue();
|
| <Snip repeating stacktrace>
| at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:110)
| at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
| at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
| at org.jboss.seam.Component.callComponentMethod(Component.java:1978)
| at org.jboss.seam.Component.unwrap(Component.java:2004)
| at org.jboss.seam.Component.getInstance(Component.java:1791)
| at org.jboss.seam.Component.getInstance(Component.java:1744)
| at org.jboss.seam.Component.getInstance(Component.java:1738)
| at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:59)
| at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:135)
| at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
| at org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
| at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
| at org.jboss.seam.core.Expressions$1.getValue(Expressions.java:115)
| at org.jboss.seam.transaction.EntityTransaction.getTransaction(EntityTransaction.java:35)
| at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
| at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
| at org.jboss.seam.Component.callComponentMethod(Component.java:1978)
| at org.jboss.seam.Component.unwrap(Component.java:2004)
| at org.jboss.seam.Component.getInstance(Component.java:1791)
| at org.jboss.seam.Component.getInstance(Component.java:1756)
| at org.jboss.seam.Component.getInstance(Component.java:1733)
| at org.jboss.seam.Component.getInstance(Component.java:1728)
| at org.jboss.seam.transaction.Transaction.instance(Transaction.java:58)
| at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:110)
| at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
| at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
| at org.jboss.seam.Component.callComponentMethod(Component.java:1978)
| at org.jboss.seam.Component.unwrap(Component.java:2004)
| at org.jboss.seam.Component.getInstance(Component.java:1791)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057078#4057078
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057078
18Â years, 10Â months
[JBoss Seam] - Seam performance concerns
by liudan2005
We did a performance test on Seam using Load Runner. The result is really disappointing. Compare with our old system(Struts based), seam is about 10 times slower. Here is the result:
Hardware: Xeon 5130 * 2 + Intel S5000 SAS + 4G 667 FBM + 15K 73G SAS RAID 10
New seam based version (using ejb3):
Environment: Seam 1.2.1 + ajax4jsf 1.1 + Myfaces 1.1.3 +
Fedora Core 6 + Oracle 10g
Test Result: 40 Transactions per second, 280 Hits per second
Old Struts based version:
Environment: Struts + Hibernate +
Fedora Core 6 + Oracle 10g
Test Result: 420 Transactions per second, 2940 Hits per second
Our system has about 150 entity beans, 100 ejbs and involves a lot of complicated logics. When our app was small, I didn't see that much difference in performance. but with time and our app becomes large, the test result is really surprising.
It could be that our new app is poorly written that makes it slow. having looked at jprofile result, I didn't see any bottleneck in our app. I still can't make a conclusion at this stage.
Is there an article talking about how to improve seam performance? In Yuan's Seam book, it mentioned a few ways to improve performance like reduce logging, server-side states saving... I've tried all of them but still can't get much performance gain.
We are in the stage of trying to improve performance as much as we can before deliver our product to our customers. Any advice would be helpful to us. Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057071#4057071
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057071
18Â years, 10Â months