Hi,
This is a cross post of http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101466
I posted on the EJB design forum about having a way to throttle ejb method invocations and Scott suggested creating an aop throttling aspect (like the asynch.* scheme).
The throttle is backed by a java.util.concurrent.Semaphore that would allow a configured number of concurrent thread requests (really semaphore permits under the covers) to proceed through the aspect.
I have this working with JBoss 4.x at the pooledInvoker level (no aspects involved) but would like to bring it into JBoss 5.x.
What do you think about the idea of having a throttling aspect?
Scott
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101471#4101471
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101471
"ataylor" wrote :
| This also keeps a single simple API for the client to use and a single point of entry.
|
| what do you think?
Ok, you sold it :)
Perhaps we should create a class called "Configuration" which maintains all the server peer attributes rather than the serverpeer directly.
And going a little further I don't think we should expose the post office attributes directly but also have them set/get on the Configuration class.
We can keep the post office class internally, but I don't think the user needs to see it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101470#4101470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101470
"clebert.suconic(a)jboss.com" wrote : If you look at StreamUtils we are converting any List (or any Map) to ArrayList and HashMap.
|
| that means if an user is using any special list (such as Vector, or any other custom lists) we are converting them to those maps.
|
|
| Because of this, I'm changing MessageSupport::getPayloadAsByteArray to call Streamutils.writeObject with containerTypes=false.
I don't think that's a good fix.If you do that it's going to use Java serialization for other message types too.
We *only* want to use Java serialization for Object messages, not for other messages like map messages.
A better fix is to override getPayloadAsByteArray on the Objectmessage.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101468#4101468
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101468
anonymous wrote : IMO: I'm more favorable of each fix on stable->same fix on trunk... so each one cleans after his own mess :-) than later having a single person dealing with merge problems.
|
Well... my other personality thinks there is one advantage about merging in batches... you only merge code after releases.. what means.. less chance of making mistakes.
Anyway... I just wanted to start the discussion.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101464#4101464
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101464
If you look at StreamUtils we are converting any List (or any Map) to ArrayList and HashMap.
that means if an user is using any special list (such as Vector, or any other custom lists) we are converting them to those maps.
Because of this, I'm changing MessageSupport::getPayloadAsByteArray to call Streamutils.writeObject with containerTypes=false.
Object*Stream is more optimized to those types anyway. And besides if you have graph dependencies on those objects, at this point we are just writing several independent objects. Say if you recover objects from Hibernate and send those over JMS they will all be flat objects after receiving.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101459#4101459
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101459