[Design of Messaging on JBoss (Messaging/JBoss)] - Messaging and Remoting - Server-side Thread-per-connection M
by ovidiu.feodorov＠jboss.com
The ServerInvoker has a bounded "ServerThread"s thread pool, the number of simultaneous invocations that can be handled at a time is limited by invoker's maxPoolSize configuration parameter. Once a "ServerThread" is allocated to a client connection, it will stay associated to that connection until the client closes the socket or a socket timeout occurs.This could lead to thread starvation in presence of a large number of clients. Increasing the number of server threads will draw down the performance because the large number of context switches.
A non-blocking NIO model would probably more appropriate here. Other messaging projects use this approach already.
Tom Elrod wrote :
| So guess would be good to cover scenarios and best approaches for them. The first scenario would be having a limited set (in the low hundreds) of clients that each regularly make invocations. In this scenario, having optimal throughput is probably the desired behavior and the current remoting code is designed for this. At the other end of the spectrum would be having a large number of clients (in the thousands) that each make periodic requests (meaning is not in tight loop that continually makes invocations). The best scenario for this is to use non-blocking i/o. The main reason for this is if use blocking i/o (besides running out of resources) will have thread per request and will be slow as balls because of all the thread context switching for all the concurrent requests. Then there are the scenarios in between (btw can add config so that remoting does not hold connection after invocation on the server side so that will free worker threads faster, which I am pretty sure is already in jira).
|
Bill wrote :
| IIRC, Tom took a lot from the PooledInvoker. The PooledInvoker had a LRU queue that closed idle connections when one was needed so that there was no starving. Also, the PooledInvoker tried to avoid a large number of context switches by associating the client connection to a specific server thread. Therefore, no thread context switches were required. Of course, this design was predicated on "keep alive" clients. So if the use case was very "keep alive" oriented, it performed really well.
|
Bill and Tom raised good issues. Where is the cutt-off line? For what number of clients an asynchronous non-blocking server-side approach becomes more efficient than the current model?
Intuitively, one can imagine, and it can be probably very easily proven, that if only two clients connect to the server, then the thread-per-connection model is as efficient (if not more efficient) than the asynchronous approach. That probably doesn't stand true anymore for a 1000 clients.
Moreover, the usage pattern for a typical JMS application is to open a connection and keep it open for the life-time of the client instance (unless one uses the anti-pattern of creating a Connection for each message sent). This seem to me a "keep alive" type of client.
We could poll our users for usage patterns, that would be interesting data.
So, in the end, it's not a matter of beliefs, but statistics. You optimize your implementation for the most common usage pattern. If the average usage pattern of a typical JMS application is to create 10-100 clients that keep sending messages periodically over a long-running Connection, I don't think it makes sense to even think about NIO at this point. Add to this that with the new distributed destinations, you can "spread" processing across nodes, so if you have 1000 clients and 4 machines, that yields 250 clients/node.
The "right" long-term solution would be Remoting to support both patterns and make this configurable. That'll make everyone happy.
Bill wrote :
| I think you should make a few prototypes and bench.
|
Tim wrote :
| At the end of the day, we will be benchmarked against QPid, ActiveMQ and others and the bottom line is, it doesn't matter how wonderful our internal architecture is, we won't be able to touch them because the benchmarks will be decided on how fast we can push bytes over sockets, and we will lose right now. Period.
|
Very good points. One more reason to start benchmarking during the early implementation phase, so we won't have surprises at the end. I am totally with you both on this.
Tim wrote :
| Much as I hate to say it, our competition has it right when it comes to their approach to remoting, actually they all seem to pretty much do it the same way (apart from us).
|
You're probably right. Do you have numbers? Maybe they're right, maybe they aren't. Would you bet your house without seeing numbers?
Scott wrote :
| I agree that there is a conflict in terms of timeframe and existing features. I don't see that there is any inherent conflict with an efficient messaging transport and an rpc transport. Its just an issue of correctly layering the concepts. The only question in my mind is whether there are sufficient issues in the tradeoff between performance and the overhead of a layered transport implementation. At this point I don't see that we can make that call.
|
Not exactly sure what you mean by "layered transport implementation". Could you please clarify?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979220#3979220
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979220
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Messaging and Remoting - Multiplexed (Bidirectional) Transpo
by ovidiu.feodorov＠jboss.com
We want to use the same physical TCP/IP connection to send data from client to server AND asynchronously, from server to client. Once this is available, the client won't need to create its physical callback server anymore. Callback servers cannot be used in firewalled environments, and even in common LAN environments they are liable to introduce complications.
Tim wrote :
| Another issue I have is the remoting core abstraction being a unidirectional connection. This forces remoting to have to introduce the concept of callback servers to be able to handle communication from the server to the client.
|
The "callback listener" model is a good abstraction to receive asynchronous notifications from the server, and it fits well with the whole remoting API. 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. Principle aside, there are also a lot of "practical" complications that arise when firewalls or funky host configurations come into play, and we had a good share of those reported by users.
Tim wrote :
| The current multiplex transport if I remember correctly has some significant overhead as compared to the standard socket transport. It's my understanding that this is due to having to design this in terms of virtual sockets so it can work with the core remoting abstraction of a unidirectional connection.
|
| If remoting had used a bidirectional connection this would have been much simpler IMHO.
|
| With a birectional abstraction, multiplex connections are not a hard problem to solve. After all you just need to encapsulate each lump of bytes written in a packet with the id of the logical connection and the length of the packet and simply correlate them on receipt according to the id and send them off to logical connections. (Actually when we get to AMQP we _must_ implement multiplex this way - we have no options since it is a requirement of the specification)
|
| I can see how this would become more difficult to implement if you only have a unidirectional remoting abstraction to work with, and have to somehow unite the two remoting connections (one in one direction and one in another) so they actually use the same connection.
|
I am sure this can be simplified, by leaving the current multiplex transport alone, and implementing a "light-multiplex" that doesn't try to offer anything like "virtual sockets", but it just carries bytes from client to server and vice-versa. I will start working with Ron or Tom on that.
Tim wrote :
| The fact is, that we can't afford any overhead in the multiplex transport since we'll lose in benchmarks because of this.
|
True. To me, this is one of the highest priority now.
Tom Elrod wrote :
| There is currently a multiplex transport (as Ovidiu noted) and how it works under the hood is explained at http://labs.jboss.com/portal/jbossremoting/docs/multiplex/multiplex.html .
| Its performance is not great (see http://labs.jboss.com/portal/jbossremoting/docs/benchmark/performance_ben... for comparison benchmarks). Ron can probably comment more on how much more performance we can expect to sqeeze out of it.
|
Tim wrote :
| I suspect this would require changes to the remoting API - specifically in the area of bidirectional connections as I have discussed.
|
Maybe not.
Let's see what Ron has to say. Ron, you have the microphone.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979219#3979219
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979219
19 years, 5 months
[Design of JBoss jBPM] - Re: extending form / task functionality
by cocampo
"tom.baeyens(a)jboss.com" wrote : a wizard always relates to 1 task. the form in that case is just spread out over multiple pages. we currently don't forsee support for that in our default webapp console forms mechanism.
|
| getting the next task of the process if it is assigned to the logged on user is fairly easy to add to the current webapp. After a user ends a task in the task form, the webapp could check if there is a new task assigned to this user. If so, navigation could be redirected to this task form instead of the task list home page.
|
| does that answer the question ?
I was thinking more of automatic execution of a form by an integrated mechanism (not having to wire it). I know you can do this via Seam, jBPM and pageflows. However, wouldn't it be better to have all this information defined in a single file? I mean, shouldn't this form-attached-to-a-task be part of the process definition? At this moment (and you can see it in the dvd-store example), you can have different jpdl definition files, and they seem unrelated among them, there is no unified view of your process and the forms it needs to run. Besides, it is not clear how roles apply to pageflows and forms; roles are (at this moment) related only to tasks, which is correct, but they should also be related to pageflows (IMHO).
On the other hand, a single file containing all this information would be (at least for complex processes) unreadable. Considering this, a single file is NOT such a good idea. Maybe, you could have multiple diagrams/files (even sub-processes), each one describing part of your process, including any necessary pageflows. This way, you don't need a huge file, but a set of related files each one describing a part of the process. So, you could model an extremely complex project, without the burden of a complex and hard to understand file. Yet, the only requirement would be that the files were related somehow (jBPM/GPD managing these relationships), because is not so useful to have multiple jpdl files and not having a precise definition of how they relate to each other.
Regarding the automatic redirect, I'm not sure if that would be a nice feature. I mean, what if you don't want to execute that task at this moment?. That?s why you have a task list, to execute tasks whenever you want.
What do you think about this?.
Regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979211#3979211
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979211
19 years, 5 months
[Design of JBoss ESB] - Re: How to store EPRs in the registry?
by mark.little＠jboss.com
"kurt.stam(a)jboss.com" wrote : 1. Gateways, ESB-unaware services - Gateways can be used by non-ESB aware clients/services to access ESB services. The addresses for these gateways can be arbitrary and shouldn't be influenced by the EPR. It seems logical to use a URI to define such and endpoint and we can store URI's in the registry (the ServiceBinding contains a URI-element)
|
The gateway concept is still under development, so I'd prefer to postpone any discussion on this until we've got that completed. Otherwise it's potentially like shooting at a moving target.
anonymous wrote :
| 2. ESB-aware services. ESB-aware services have a fully populated EPR and all of this information can no longer be stored in an URI. The current thinking is to store the entire XMLized EPR to the registry.
|
That approach has precedent with Web Services.
anonymous wrote :
| To store WSDL the tModel is used (in JAXR this is a Concept(fingerprint) and/or Classification(namespace), see also http://java.sun.com/developer/technicalArticles/WebServices/jaxrws/
|
We'll certainly need to store WSDL and other contract definition information later, as we really explode how the ESB uses the Registry. At the moment we're really looking at the first steps though: more like a basic naming service. So I wouldn't expect we're looking at anything more complex than an EPR. Would you?
anonymous wrote :
| . We may want to store the EPR-XML in the same place. If we do so, what will we put in the URI reference for the ServiceBinding. Maybe something like "epr://jbossesb" to define what type of 'protocol' we are using.
|
| Well I hope this is enough to start a discussion on this matter.
|
| --Kurt
Is this not where the Logical Name comes in? From the outset we've talked about two types of names:
(i) the "physical" name, which is the EPR and needed to address the service. This name may be obtained from the Registry or from elsewhere. But the Registry is the preferred approach.
(ii) the "logical" name, which is a convenient short-hand, like "Kurt's Travel Agency". Obviously in order to interact with a service you need a real address, so if all you've got is a logical name you need some way of mapping one to the other. That's where the Registry comes in again. The Registry maintains a tuple space of <logical name, physical name>.
We could set the logical name as the URI. As you say, something like: epr:jbossesb:version:1.0:logicalname:KurtsTravelAgency
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979203#3979203
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979203
19 years, 5 months
[Design of JBoss ESB] - Re: How to store EPRs in the registry?
by mark.little＠jboss.com
We're assuming that the Registry is available to both ESB-aware and ESB-unaware clients/services.
(i) If ESB-unaware services want to register in it for use by ESB-unaware clients then the format they use for storing information is entirely up to them, i.e., we don't need to worry about it.
(ii) if ESB-unaware services want to register for use by ESB-aware clients, then we obviously can't require that those services register EPRs because they are ESB-unaware. However, since our clients are ESB-aware, they'll expect EPRs to address those services, which means that the use of an external gateway is the way to go: the EPR addresses the gateway, which then translates the request message as well as redirecting the resulting message to the real service.
(iii) if ESB-aware services want to register for use by ESB-unaware clients, then they publish their addresses as EPRs, since that's what ESB-aware services do naturally. We would develop a series of gateways to map EPRs to ESB-unaware address formats; these formats will typically be tied to the client's deployment environment (e.g., JEE or CORBA), so there will need to be a series of these adapters.
(iv) if ESB-aware services want to register for use by ESB-aware clients, then they publish their addresses as EPRs and the clients use those EPRs.
I think that just about covers it for now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979199#3979199
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979199
19 years, 5 months
[Design of JBoss ESB] - How to store EPRs in the registry?
by kurt.stam＠jboss.com
Now that the registry is ready it's time to put something in it. We seem to have 2 classes of services:
1. Gateways, ESB-unaware services - Gateways can be used by non-ESB aware clients/services to access ESB services. The addresses for these gateways can be arbitrary and shouldn't be influenced by the EPR. It seems logical to use a URI to define such and endpoint and we can store URI's in the registry (the ServiceBinding contains a URI-element)
2. ESB-aware services. ESB-aware services have a fully populated EPR and all of this information can no longer be stored in an URI. The current thinking is to store the entire XMLized EPR to the registry. To store WSDL the tModel is used (in JAXR this is a Concept(fingerprint) and/or Classification(namespace), see also http://java.sun.com/developer/technicalArticles/WebServices/jaxrws/
. We may want to store the EPR-XML in the same place. If we do so, what will we put in the URI reference for the ServiceBinding. Maybe something like "epr://jbossesb" to define what type of 'protocol' we are using.
Well I hope this is enough to start a discussion on this matter.
--Kurt
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979195#3979195
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979195
19 years, 5 months