July 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - leasing in JBossCache

by testuser1234

Hi All, Can anybody please help me in knowing how can we mention lease time in JBossCache and can we just keep objects in memory instead of persistence storage to database etc.? Also how listeners/receivers work in JBossCache? I mean do they need to provide some template to cache for retrieving objects or it is simple key based. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167285#4167285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167285

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by trustin

"ron.sigal(a)jboss.com" wrote : For an EJB3 in AS 5 to be accessible from both AS 4.2 and AS 5, then | | 1a. either, as David says, there would have to be two EJB3 implementations running on the server, or | | 1b. we would have to turn org.jboss.aspects.remoting.AOPRemotingInvocationHandler into a bean that could be shared by both Remoting 2 and Remoting 3, I'm not following this. Could you explain a little bit further? Regarding 1a, I thought what we need to do is to run two Remoting versions (2 and 3) which calls local EJB3? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167273#4167273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167273

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by trustin

"ron.sigal(a)jboss.com" wrote : "trustin" wrote : | | The socket and bisocket transport will run on XNIO / Netty. It's to make sure that R2 clients can talk to R3 services. It doesn't mean we are going to retain the old socket I/O code. | | | | Correct me if I'm wrong, but I was under the impression that, for a moderate number of worker threads, the old style blocking model outperforms NIO. If so, I would argue that, not only does it make sense to implement a new version of the socket transport, but it also makes sense to preserve the old version as well. I thought XNIO provides a blocking transport? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167266#4167266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167266

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing MC notion to Seam/ServletContext

by alesj

This is done: - https://jira.jboss.org/jira/browse/JBAS-5808 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167258#4167258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167258

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @RemoteBindings and clientBindUrl - JNDI binding questio

by jaikiran

"ALRubinger" wrote : "jaikiran" wrote : Currently, I can't specify that the @RemoteBinding with a CUSTOM_CLIENT_BIND_URL is for the "AnotherRemote" business interface | | Sure, see my last post; put it on the interface itself, not on the class. | | Oops, i had missed that point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167220#4167220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167220

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by ron.sigal＠jboss.com

"trustin" wrote : | I think we can make the XNIO-based protocol implementation look similar to that of Remoting 2 socket transport. As David explained in the IRC channel, we could simply retain the core classes which are serialized and deserialized in R2 and convert them to R3 classes and vice versa to implement R2 compatibility: | There's also the non-invocation protocol elements to worry about. That is, in addition to ordinary invocations, org.jboss.remoting.ServerInvoker handles connection monitoring, callbacks, and streaming. But Tim gives me an idea. To my knowledge (and Scott can correct me if I'm wrong :-) ), JBossMessaging is the only JBoss project that uses leasing and callbacks. And since JBM 1 (which lives in EAP 4.2) and JBM 2 (which I assume will live in EAP 5) are not compatible, the need to support these features in the Remoting 2 <-> Remoting 3 compatibility solution plummets in urgency. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167213#4167213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167213

17 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBoss 5.0.CR1 and JSF Error

by richard.opalka＠jboss.com

Hi poss, this is the wrong forum for your problem. Use this user forum instead. Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167211#4167211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167211

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by ron.sigal＠jboss.com

"timfox" wrote : | IMHO the R2 socket protocol suffered from fundamental design flaws and trying to copy them in R3 means copying those flaws too... ? | The other day we watched a documentary on HBO about great boxers of the twentieth century. There was some amazing footage of Jack Dempsey and Gene Tunney, probably well into their sixties, meeting in formal evening clothes and sparring in a ring. They pretended to throw some punches, and, after a little while, they grabbed each other and started ballroom dancing. It was very sweet. Talking about the incompatibilities between JBossRemoting and JBossMessaging reminds me of two old boxers, meeting one more time. :-) What Tim calls "design flaws" I would call "design decisions". The fact is that the socket transport was derived from the PooledInvoker, which was meant to support EJBs and a remote method invocation model. And EJB/EJB3 + Remoting just works. In two and a half years, I recall making exactly one change in Remoting on behalf of EJBs. JBM + JBR, on the other hand, has always been a more difficult fit. A lot of work has been done, on both sides, to make it work, and I'm very happy that JBM 1 has been successful. I'm also relieved that JBM 2 will have a more appropriate foundation. "trustin" wrote : | The socket and bisocket transport will run on XNIO / Netty. It's to make sure that R2 clients can talk to R3 services. It doesn't mean we are going to retain the old socket I/O code. | Correct me if I'm wrong, but I was under the impression that, for a moderate number of worker threads, the old style blocking model outperforms NIO. If so, I would argue that, not only does it make sense to implement a new version of the socket transport, but it also makes sense to preserve the old version as well. So, Tim, do you want to be Dempsey or Tunney? :-) -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167209#4167209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167209

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by ron.sigal＠jboss.com

"david.lloyd(a)jboss.com" wrote : | "david.lloyd(a)jboss.com" wrote : | | "trustin" wrote : | | | We can run both R2 and R3 at the same time in the microkernel, so R2 users should be able to keep using R2 services or upgrade to R3. | | | | | This is true; however then we will have not only both versions running, but all services will have to have an R2 and R3 version. This might be difficult to do in some cases where the Remoting implementation is tied to the service (like the UnifiedInvoker for example). | | | | Not that I want to rule this out mind you. I'm just expressing that this difficulty does exist. | For an EJB3 in AS 5 to be accessible from both AS 4.2 and AS 5, then 1a. either, as David says, there would have to be two EJB3 implementations running on the server, or 1b. we would have to turn org.jboss.aspects.remoting.AOPRemotingInvocationHandler into a bean that could be shared by both Remoting 2 and Remoting 3, and 2a. either EJB3 would have to create two separate proxies, or 2b. org.jboss.aspects.remoting.InvokeRemoteInterceptor would have to be able to talk to both Remoting 2 and Remoting 3, which means 2ba. either it would have to probe its environment to determine which version of Remoting is available (could be a System property), or 2bb. we would have to provide a Remoting 2 facade for Remoting 3 so that InvokeRemoteInterceptor doesn't need to know which version of Remoting is running. As for 1, would having two implementations of the same SFSB running simultaneously cause a problem? 2a seems distasteful. As for 2ba versus 2bb, that's a separate issue. Having a Remoting 2 facade would be *nice*, but maybe not urgent. For me, the overriding consideration is that all of these changes, while seemingly doable, amount to spreading all over the Application Server something that should be handled discreetly in Remoting. 1a+2a is particularly egregious in this respect. I think we could live with 1b+2ba, since org.jboss.aspects.remoting is part of the integration of Remoting into the Application Server. I would say that 1. 1b+2ba should be our minimal goal, and 2. hiding everything inside Remoting proper is preferable, since it better serves standalone users. The latter seems to imply a "socket" transport in Remoting 3. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167208#4167208 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167208

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @RemoteBindings and clientBindUrl - JNDI binding questio

by ALRubinger

"jaikiran" wrote : Currently, I can't specify that the @RemoteBinding with a CUSTOM_CLIENT_BIND_URL is for the "AnotherRemote" business interface Sure, see my last post; put it on the interface itself, not on the class. A more sticky subject here is HTF do we support this in jboss-xml? ;) For that we *would* need a "target-interface"-type element. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167202#4167202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167202

17 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2008