testPooledOldProxy(org.jboss.test.pooled.test.BeanStressTestCase)Success 20.357 testPooledNewProxy(org.jboss.test.pooled.test.BeanStressTestCase)Success
45.860 testRmiOldProxy(org.jboss.test.pooled.test.BeanStressTestCase)Success
29.227 testRmiNewProxy(org.jboss.test.pooled.test.BeanStressTestCase)Success
259.172
I changed to 500 threads...
when i put 600 I get lack of memory errors... how do I change the amount of memory available in jboss??
is secure to share the same proxy among so many threads???? I know i would have a wrapper in case of server restart.
Hiram Chirino wrote:
That's the way It kinda works now, but I don't like it because it's not generalized. We don't have to do that with RMI proxies today, why do we have to do that with trunk proxies? And RMI proxy could be sent down the the invocation as an argument and all would be ok. You should be able to do the same with a trunk proxy.
Regards,
Hiram
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Bill Burke
Sent: Monday, November 18, 2002 11:57 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations
Why does the proxy object have to setup the callback channel on
deserialization? Just stuff the proxy in the invocation object as
party of the payload. Invoker pulls this proxy shell out of the
invocation and initializes it with the real callback channel..
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf
Of Hiram Chirino
Sent: Tuesday, November 19, 2002 4:03 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations
I agree.. same socket bi-directionality is exotic and does not
have to be in the public interface.
Currently, it's not very nice how the proxy going back client
gets setup. I won't go into details about the current way I do
it (it sucks).
Here's the route I hope I can change too soon:
1) client sends a proxy object down an invocation to the server..
2) server invoker sets either (a) an Invocation attribute or (b)
and ThreadLocal to identify the socket the invocation came over.
3) When the proxy object is de-serialized, he looks up the
object in (2) to setup the callback channel to go through the
original socket.
But for this to work in the (a) case the proxy object would
need to be able to access the Invocation object during deserization.
And for it to work in the (b) case the proxy object has to be
deserialized while in the context of the thread the invocation
came in.
I don't think I'll be able to do this the way invocations are
done right now. You think this is a bad route? Regards,
Hiram
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf
Of Bill Burke
Sent: Sunday, November 17, 2002 11:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations
I agree Scott (no public interface for bi-directionality). It will be tricky to implement the bi-directional behavior
if Invokers don't have a bi-directional public interface. I
wonder how you abstract this out now Hiram.
One way to do this would be to use the trick I used with
EJBs and multiple-invokers. 1. Have a proxy factory.
2. Pass this information with the client request.
3. Look up the proxy factory whenever you have to create
proxies via the tag in the invocation.
Bill
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Scott M Stark
Sent: Saturday, November 16, 2002 1:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] new PooledInvoker: speeds up
invocations
It should be possible to route invocations over the
incoming channel, but it cannot be
a requirement. This does not imply the invocation
interfaces are bi-directional however.
There simply needs to be the ability to compose the
invokers such that there is a shared
communications channel.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: Victor Langelo
<mailto:[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 7:11 PM
Subject: Re: [JBoss-dev] new PooledInvoker: speeds
up invocations
Hiram Chirino wrote:
Hiram Chirino wrote: > Anyways. JMS need bi-directional invocations (BADLY). Should this > become a requirement for the other invokers??I completely disagree. There is no reason server to client communication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature: This allows callback to clients that are sitting behind a firewall.Let me agree with Hiram. I would add it is essential to use the client connection if the client network is using NAT (network address translation). With the advent of new security measures, many of our clients are adding firewalls and NAT. The worst case is when the server has a public IP and the local LAN clients are on the otherside of a NAT router. --Victor
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxx | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959 | | SICREDI Serviços | | Porto Alegre - Brasil | |xxxxxxxxxxxxxxxxxxxxxxxxxx| ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
