October 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Server-side Thread-per-connection Model

by scott.stark＠jboss.org

"tom.elrod(a)jboss.com" wrote : | This way, would be possible to just use that low-level transport layer where just dealing with raw data, instead of having the ?everything is an object? type view pushed on you by the higher level API. | | If this is what Scott is saying (and hope it is), then I agree. | | Yes it is. The lowest level is a raw msg that works with the asynch io frameworks (NIO, APR, ...), another layer is the payload format, and another layer is marshalling/unmarshalling to objects. One needs to be able to plugin both the raw msg handling and payload format so that complete wire specifications like ampq and iiop (we talked about this long ago) can be handled. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979242#3979242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979242

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls

by tom.elrod＠jboss.com

anonymous wrote : | In what release is this available? I would like to play a little bit with it. | It is in HEAD and targeted for 2.2.0.Beta1 (Bluto) (which is already past due and probably won?t be out for a while). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979241#3979241 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979241

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Server-side Thread-per-connection Model

by tom.elrod＠jboss.com

anonymous wrote : | The "right" long-term solution would be Remoting to support both patterns and make this configurable. That'll make everyone happy. | Absolutely anonymous wrote : | Not exactly sure what you mean by "layered transport implementation". Could you please clarify? | Remoting currently views things in terms of the Object world, meaning at the highest API level, it expects to be dealing with objects. Then as dive deeper in the guts of remoting were have transport and marshalling, the same theme still exists (although not as tightly constrained). Think what Scott is talking about is having the transport layer so that at lowest level is only dealing with raw data, then passes that data to a higher level, where would be converted into whatever format (an Object for example), then pushed up. This way, would be possible to just use that low-level transport layer where just dealing with raw data, instead of having the ?everything is an object? type view pushed on you by the higher level API. If this is what Scott is saying (and hope it is), then I agree. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979239#3979239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979239

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Multiplexed (Bidirectional) Transport

by tom.elrod＠jboss.com

anonymous wrote : | What I don't agree with is the need to have callback servers, as in pieces of code wrapped around server sockets on the client side . Once you have a TCP/IP connection from client to server, use that and don't open another one from server to client. | Although a callback server is needed on the client side, this does not necessarily mean a server socket is needed. If using the multiplex transport, it can use the same client socket to receive call back from the server (using virtual sockets). I have tested this through my firewall and know that the multiplex transport supports this. So think the functional requirement of multiplex is already met. Now would be a question of either performance not being good enough or programming model not fitting. I agree that we need Ron's input as to how much more performance gains can realistically be expected of the multiplex transport. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979236#3979236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979236

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Changed recurse notions in VisitorAttributes, VFS.visit

by scott.stark＠jboss.org

The recurse and recurseArchives notions in the VisitorAttributes have been replaced with a more general VirtualFileFilter recurseFilter. The filter controls whether recursion of non-leaf files is done: | public class VisitorAttributes | { | ... | /** | * Whether to recurse into the non-leaf file<p>. If there is a recurse | * filter then the result will be its accepts(file) value. | * | * Default: false | * | * @return the recurse flag. | */ | public boolean isRecurse(VirtualFile file) | { | boolean recurse = false; | if( recurseFilter != null ) | recurse = recurseFilter.accepts(file); | return recurse; | } | | /** | * Get the recurse filter. | * @return the current recurse filter. | */ | public VirtualFileFilter getRecurseFilter() | { | return recurseFilter; | } | | /** | * Set the recurse filter. | * | * @param filter the recurse filter. | * @throws IllegalStateException if you attempt to modify one of the preconfigured static values of this class | */ | public void setRecurseFilter(VirtualFileFilter filter) | { | this.recurseFilter = filter; | } | ... | with this, it looks like I can implement the ejb3 deployment scanning without having to do a structural parse. This would only be needed if more control over how a deployment context classpath affects the scanning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979234#3979234 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979234

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls

by ovidiu.feodorov＠jboss.com

Tim wrote : | In many cases with messaging we don't want RPC (in some cases we do). | This is a table that contains ALL client-to-server interactions, represented as metod signatures. | Method Name Return Value | ConnectionFactoryEndpoint | createConnectionDelegate() ConnectionDelegate | getClientAOPConfig() byte[] | getIdBlock() IdBlock | ConnectionEndpoint | createSessionDelegate() SessionDelegate | getClientID() String | getPreparedTransactions() Xid[] | isClosed() boolean | setClientID() - | start() - | stop() - | sendTransaction() - | close() - | closing() - | SessionEndpoint | createConsumerDelegate() ConsumerDelegate | createBrowserDelegate() BrowserDelegate | createQueue() JBossQueue | createTopic() JBossTopic | isClosed() boolean | acknowledgeBatch() - | acknowledge() - | addTemporaryDestination() - | deleteTemporaryDestination()- | unsubscribe() - | send() - | cancelDeliveries() - | close() - | closing() - | ConsumerEndpoint | isClosed() boolean | more() - | close() - | closing() - | BrowserEndpoint | nextMessage() Message | hasNextMessage() boolean | nextMessageBlock() Message[] | | This table lists server-to-client interactions. | Method Name Return Value | | MessageCallbackHandler handleMessage() HandleMessageResponse | | I don't think that methods that return a non-void result need arguing (with the exception of MessageCallbackHandler.handleMessage(), which I will talk about later). They represent round-trips to the server, and they are invoked because the client needs something from the server. The client cannot continue unless it has the reply it needs, so trying to suggest to replace these with asynchronous calls just for the sake of it seems to me at least questionable Now let's analyze the methods that don't return anything, but represent life-cycle operations, and rarely used mutators (ConnectionEndpoint's start(), stop(), close(), closing(), setClientID(), SessionEndpoint's addTemporaryDestination(), deleteTemporaryDestination(), unsubscribe(), close(), closing(), ConsumerEndpoint's close() and closing()). How many times a second do you start, stop or close connections? Or how many times a second do you add or delete temporary destinations. These are life cycle methods (we use DEBUG to log them), why would they need to be optimized for speed, when reliability and the convenience of getting the acknowledgment of their successful completion (or not) are much more important? Optimizing these operation do not improve message throughput, which is in the end all that matters. ConnectionEnpoint.sendTransaction(). When your transaction successfully completes on the server (or, more importantly, when it does not), your client wants to know. Using an RPC style invocation makes propagating exceptions back easy. The alternative would be to asynchronously send the "transaction" and then somehow listen for a confirmation (positive or negative). What would be the benefit of doing that? SessionEndpoint.send(). See the previous "correct approach" discussion. If you don't invoke this method synchronously, how does the client know that the message has been accepted by the broker? SessionEndpoint.cancelDeliveries(). This is used to cancel any undelivered messages left in the client buffer when the consumer is closed or to cancel any messages that couldn't be redelivered locally at session recovery. Both cases are extraordinary events that do not impact message throughput performance in any way. This leaves us SessionEndpoint.acknowledgeBatch(), SessionEnpoint.acknoweldge() and ConsumerEndpoint.more() that can arguably improve the throughput if they're made asynchronous. Also, sending the message to the client for delivery is a good candidate for asynchronicity. So, getting back to what you said, "In many cases with messaging we don't want RPC (in some cases we do).", I would actually say that in many cases with messaging we want RPC, and is some very special cases we don't. Remoting should support both modes, and we should choose carefully how we use them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979228#3979228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979228

19 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: org.jboss.remoting.CannotConnectException (ejb3)

by andrepintorj

I have right now *exactly* the same problem... I'm trying to access a bean over a NAT, but I don't want to hard code the external IP on the beans since the IP is not static... So, I hope there is a solution soon. BTW, I would like to set the param "clientConnectAddress" as a URL and not an IP number since I want to use it with a dynamic IP number and a service like "no-ip"... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979225#3979225 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979225

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by ovidiu.feodorov＠jboss.com

Seems we're converging towards "do it outside Remoting first and integrate later" or just straight "do it inside Remoting". The multiplexed (bidirectional) transport is the highest priority and also it's possible to tackle it "inside Remoting". Here is a dedicated discussion thread. I've summarized the discussions so far, and I added some suggestions and questions: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979219 The server-side thread-per-connection issue is something that 1) is being worked on by Tom and 2) requires further discussions as where is actually the cut-off line where an asynchronous solution is really necessary. Please read and comment here http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979220. The "true" client-side asynchronous calls seem to be also taken care of already. Here is the summary, with some additional open issues: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979221 The control of the wire format seems to be the really difficult one, in the context of the actual Remoting. This is the dedicated thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979222. Need more input there. Tim wrote : | At the end of the day we want to build the best messaging system out there and don't want to be prevented from this goal because of this. | Amen to that :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979223#3979223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979223

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Remoting - Ability to send unformatted data

by ovidiu.feodorov＠jboss.com

This is required to support AMQP. Tom Elrod wrote : | It is possible to send and receive raw payload data using remoting where is not wrapped in the remoting InvocationRequest/InvocationResponse using configuration per request. | Right, but this assumes an initial invocation made by a Remoting client. The issue that we have to deal with here is that a completely unknown client (that may be written not even in Java) sends AMQP frames, and Remoting has to parse them, or at least delegate the parsing to a pluggable module. As far as I know, this is beyond of Remoting's capabilities, today. More on this: Tim wrote : | We should bear in mind, that at some point (not too long) we probably need to support the AMQP protocol. The AMQP protocol defines a full wire format protocol down to the last byte. Including the wireformat of the multiplex, heartbeats etc. | I don't see how we would get that to work with remoting. So we would have to do major work then _anyway_. | Some other (valuable) musings: genman wrote : | In my opinion, it's quicker (and oddly pleasant) to craft something out of a formal specification, than to work on your own protocol. How does it go? "Bad artists copy. Great artists steal." | Right. We didn't think to do it otherwise :) genman wrote : | You need a framing protocol, and I would get to work implementing AMQP right away. Then later, or simultaneously, abstract AMQP into one of the JBoss remoting system. | That sounds to me like a suggestion to "do it quick and dirty now and integrate later". The discussion is open. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979222#3979222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979222

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Remoting - Client Asynchronous Calls

by ovidiu.feodorov＠jboss.com

Messaging clients should be able to send data on the wire without the unnecessarily added burden of waiting for a reply. Similarly, the server should be able to asynchronously send data to the client. Tom Elrod wrote : | Have made the code changes (for jira issue http://jira.jboss.com/jira/browse/JBREM-548 ) so that if doing one-way invocations, only the request ever gets written to the wire and that thread on the client returns immediately after the write. On the server side, it never writes the response back to client. | In what release is this available? I would like to play a little bit with it. Tom Elrod wrote : | Probably good to have better definition of what asynchronous means. At a high level in the call stack, can just mean using a future model to make call and wait for a response to come back at later point in time (or just a callback on a different thread at later point in time). At lowest level, could be talking about only writing on the wire and not waiting for response off the wire. Lots of places term can be used in between the high and low level. | In what I am concerned, asynchronous means the ability of using a client thread to put data on the wire and return immediately without waiting for any reply. "True" asynchronicity in this context means that no unnecessary work is done (like sending a reply but discarding it on the client side). Tim wrote : | Here is a an example that came up in the forums the other day (there is also a support case related to this from another customer with JBossMQ which suffers from a similar problem): | | The customer has a fantastic high bandwidth network, but it has very high latency (large round trip time). They would love to use their network to it's capacity with our messaging product. Currently when we deliver messages (usually one by one) from the server to the client consumer they are delivered by a remoting RPC call. This writes to a socket then waits for a response. Therefore the minimum amount of time to send one message is 2 x latency. And this is for every message (!). | The "correct" way to do this is to forget responses, just write to the socket and carry on. Flow control messages from the client to the server then prevent the client being overrun with messages (this is kind of analogous to how TCP flow control works - although there are some differences). | Your "correct" approach raises the following issue: Assume that you want to write a client that needs guaranteed delivery on a queue. You write that client to create a persistent message and send the message by invoking a producer's send() method. As soon as your send() method returns without an exception, this is a hard guarantee to your client that the messaging broker accepted the message for further delivery. You cannot have that guarantee without you call actually reaching the server. At that point, the client can call System.exit() and go to the client's heaven, fully assured that his message is being taken care of. If you use the asynchronous approach you describe, the client will be never able to rely on this guarantee. Tim wrote : | Moving on to serialization. JBoss Remoting is based around the idea of invocations that get serialized. We a) don't want invocations and b) In almost every case we don't want serialization either (there is one case we do want serialization) - this is because we know the types of the objects being transmitted at compile time so we can encode that information in a much more efficient way (in a byte) - the overhead of serialization is just to much for us. | I disagree with a). An RPC model is very convenient when dealing with life cycle operations such as creating connections, sessions, producer, consumer, browsers, etc. It's a very convenient model for a high granularity reliable operations. The alternative would be to send an asynchronous invocation to say, create a Session, and then block on the client for an explicit acknowledgment from the server. Why would you want to do that when you have RPC for free? I agree with b), though. This is an overhead we can do without. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979221#3979221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979221

19 years, 5 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 October 2006