[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting
by timfox
"ovidiu.feodorov(a)jboss.com" wrote :
| So, I agree that there is an efficiency problem with using byte[] instead of direct ByteBuffers, but saying that an interface that use byte[] cannot inherently work with a NIO runtime is just wrong. A byte[] has nothing to do with non-blocking-ness per se.
|
Well I don't think I ever said that.
The point I was making is that we shouldn't *prevent* people from using direct buffers if they want, by forcing them to use byte arrays.
I think it's a bad API that doesn't allow the user to exploit the full available power. Certainly the user should be careful, but it's user errror if they screw up.
I think we have no (at least tacitly) agreed that byte buffers should be exposed, not byte[] so this is rather moot.
anonymous wrote :
| Tim wrote :
| | This is what non blocking is all about. A blocking implementation would block until all the bytes had been written. This preventing the thread neing used for anything else while the blocking is occurring.
| |
|
| No, this is not what non blocking is all about.
|
This *is* what non blocking is all about. Certainly NIO has other nice things like byte buffers and charset support, but we're talking about blocking here not NIO in general.
By avoiding blocking on reads or writes it enables a small number of threads to handle a large amound of "connections". If reads or writes were blocking that wouldn't be possible. That's the crux of the matter.
"Ovidiu" wrote :
| There are two different (and orthogonal) aspects: non-blocking behavior + readiness selection AND direct buffers. You can avoid using direct buffers if you want to, and still get non-blocking behavior at the "lower" level of your framework. In the end, you want to achieve separation between your client code and the transport.
|
| Tim wrote :
| | This also means it's going to be up to the application to piece together requests and responses.
| |
|
| No.
|
| Let's walk through a simple example. Let's say that you want to send a message acknowledgment from the client to the server, saying that message with id = 77 has been successfully processed by the client code...
|
To re-iterate what I said earlier.
Yes, you can handle the partial reads/writes in the framework which is basically what you are proposing.
However, this is one of the major value adds of NIO frameworks like MINA (I don't know about ember but I wouldn't be surprised if it did this too), so we are now getting into the realms of writing our NIO framework, and now the warning bells are ringing. Why not just use one that we know works?
Frameworks also seem to handle other stuff like byte buffer pooling (important with direct buffers as you have pointed out) and allow different selector/worker thread models to be used.
Also SSL support is built in (with MINA at least) although this is only with JDK5.
"Ovidiu" wrote :
| We will decide on a solution at the end of the remoting meeting that will take place this week. The solution I propose is one of the possible outcomes. Using an external framework it's another. Nothing is a priori overruled.
|
Great :)
My 2c (again):
Facts:
a) We need NIO. (I'm not even mentioning multiplex here)
b) Remoting doesn't support NIO as we require it.
c) Other NIO frameworks exist which support what we want to do.
d) We must have this done in 4 weeks.
Options:
a) Write our own NIO framework. (Alarm bells!!)
b) Use an NIO framework that already exists
c) Wrap remoting around an existing NIO framework, and hope that remoting can somehow provide a better API.
Conclusions:
a) This is far too time consuming and error prone.
b) Is my preferred solution
c) Is something worth exploring, but I fail to see what value remoting would add by wrapping the underlying NIO interface. What could it do better?
I would suggest b), then in phase 2, see if it makes sense to combine this with remoting somehow.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980645#3980645
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980645
19 years, 5 months
[Design of JBoss ESB] - Re: Design of a Content Based Routing Service
by mark.little＠jboss.com
"kurt.stam(a)jboss.com" wrote : anonymous wrote : Upgrading to JBossRules 3 will mean rewriting the DSL, which is fine. I haven't looked at how it's done in the new version, but it was dead simple to write a DSL for Drools. What do you mean by "plain java implementation?"
| Right, and using the JBossIDE2.0 it seems even easier. We'd like to keep our implemenation POJO based, but I realize that one would like to have only 1 CBR service running, where clients (listeners) connect to. This would make reloading the ruleset more manageable. I'll talk to Mark about this one.
|
One single service is always a good deployment choice in general, since it makes management easier, but the architecture we should be looking at supporting is multiple services, potentially a CBR per client/service.
anonymous wrote :
| anonymous wrote : Do you want to support a single language for rule matching (e.g. XPath) or leave it open-ended/extensible?
| I think it make sense to leave it open-ended. Do you think this would be more work for us?
|
| anonymous wrote : I suppose that would only work if the CBR service returns an action name instead of forwarding the message. Well the CBR could first apply the rules, obtain one or more action/service names, then send messages to each of these destinations.
|
Not sure if this helps, but one update Tom made recently allows the Action Chaining rules to be associated with (shipped with) a message and interpreted dynamically at the receiver.
anonymous wrote :
| anonymous wrote : is there even the concept of synchronous and asynchronous messages?
| Well I don't think it matter whether or not it is synchroneous, for instance in our loanbroker example we send out the loanrequest to 2 banks and receive 2 quotes. We listen for both quotes to come in, before processing the quotes. Typically the message flow is asynchroneous, and a separete listener (different thread) will listen for a response. However within an action pipeline things go synchronous (things like the transformation of a message into a different format). Hmm.. just thinking out loud here but I think the if the CBR would be at the end of an action pipeline, then mutliple desitinations would be no problem.
|
| Can we conclude that CBR can only happen as the last step in an action pipeline? That seems to make the most sense to me.
|
I think at present, with the current architecture based on listeners and actions and action chaining, we can impose whatever restrictions are required.
anonymous wrote :
| Then I thought of some more interesting questions:
| - will we use a rules repository (will this be a database? And if so will it have it's own schema?) I think you use an xmlfile, read from an url somewhere right?
| - how do you update the rules? You use an mbean for that right?
The Rules team are building their own rules repository. We should leverage that when it's available. In the meantime, we should provide something that is good enough, but doesn't require implementing an entire repository ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980638#3980638
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980638
19 years, 5 months
[Design of JBoss ESB] - Re: Design of a Content Based Routing Service
by mark.little＠jboss.com
"kurt.stam(a)jboss.com" wrote : I've been looking at the donated cbr code (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86937, thx for that btw :)) and I think that for us to use it we need to make the following changes:
|
| 1. Technology:
| a. upgrade to the latest JBossRules (3.x)
| b. move towards the new java-like rules definition
| c. move to a plain java implementation
|
| 2. Integration
| a. Name the CBR as an action and define a processor for it, or in the architecture to come,
|
Sounds very like Hitchhiker's Guide to the Galaxy ;-)
anonymous wrote :
| define the CBR as a Service and register it's ServiceBinding in the Registry
|
I'm not sure if it would be a service or some logic within the dispatcher, which could use an external service I suppose.
anonymous wrote :
| b. Add the CBR action as a (routing) action in the action chain.
|
| 3. Questions
| a. Should the CBR service return a service/action name, or should it actually forward the message straight to it.
|
Can you go through the scenario you have in mind?
anonymous wrote :
| b. Do we support routing to one or multiple destinations for the next release?
|
One would be a good start.
anonymous wrote :
| c. Our messages are either of type Serializable or XML, will we support the content based routing of both types (or just XML)?
|
Since the message formats can be extended arbitrarily and at runtime, I'd expect the CBR implementation to be suitable extensible too. We provide necessary plugins to support the out-of-the-box message formats we have, and use an architecture that allows others to add their own CBR-handlers at runtime.
anonymous wrote :
| d. What happens when no rules match? Do we have to create a 'catch all' rule, or is it ok to return 'sorry'. What will happen next? Will the message simply go to the next action?
|
| Dave I'd love to hear your, or anyone elses, thoughts on any of this.
|
| --Kurt
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980637#3980637
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980637
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting
by ovidiu.feodorov＠jboss.com
There are at least two distinct aspects that we need to discuss when talking NIO optimization.
First there is the fact that a non-blocking IO implementation, complete with readiness selection, allows a single thread (or a precisely limited number of threads) to efficiently do what in a thread-per-connection model would take a number of threads equal with the number of connections. This approach a) avoids thread context switching that becomes toxic after the number of threads in use reaches a certain threshold and b) prevents using the thread scheduler as a substitute for a readiness selection mechanism (threads that suddenly get something to read, or write, are un-blocked by the scheduler, which acts as a "de facto" readiness detector).
The second advantage of using NIO is the fact that, thanks to direct buffers, JVM client code can read and write directly physical memory that is also directly accessed by device drivers (the network driver or the DMA subsystem). The java code has no idea that it actually doesn't write JVM heap, but physical memory that is also mapped in the kernel space, so it can be directly accessed by the said devices. Regardless of how it is actually done, the net benefit is avoiding copying bytes over. However, one must keep in mind that direct buffers are much more heavier entities than simple byte arrays, they take a lot more time to allocate, and they are not subject to JVM memory management and garbage collection.
So, the thing I want to point out is that these two different aspects are ORTHOGONAL. I can pass a byte[] to a NIO implementation, and the implementation can make sure the buffer is completely read (or written) the same way it would make sure a ByteBuffer is completely read and written (and yes, that's true, by internally creating a direct ByteBuffer and copying bytes over).
So, I agree that there is an efficiency problem with using byte[] instead of direct ByteBuffers, but saying that an interface that use byte[] cannot inherently work with a NIO runtime is just wrong. A byte[] has nothing to do with non-blocking-ness per se.
Tim wrote :
| This is what non blocking is all about. A blocking implementation would block until all the bytes had been written. This preventing the thread neing used for anything else while the blocking is occurring.
|
No, this is not what non blocking is all about. There are two different (and orthogonal) aspects: non-blocking behavior + readiness selection AND direct buffers. You can avoid using direct buffers if you want to, and still get non-blocking behavior at the "lower" level of your framework. In the end, you want to achieve separation between your client code and the transport.
Tim wrote :
| This also means it's going to be up to the application to piece together requests and responses.
|
No.
Let's walk through a simple example. Let's say that you want to send a message acknowledgment from the client to the server, saying that message with id = 77 has been successfully processed by the client code.
With the API that I am proposing, you can do this:
You allocate a byte[] of five bytes. The first byte is the operation code. Let's assume for the sake of the example that the acknowledgment operation code is 11. The rest of four bytes contain the message id. So you end with a { 0x0B, 0x00, 0x00, 0x00, 0x4D } byte array, that you just hand over to "remoting" (or whatever superstructure based on NIO you want to use). The "remoting" module would wrap the byte[] in a ByteBuffer and passes it to a SocketChannel, writing it in a non-blocking manner on the channel using the thread it manages.
Your client thread returns immediately, and your { 0x0B, 0x00, 0x00, 0x00, 0x4D } acknowledgment will be, eventually, sent on the wire, by the "remoting" layer thread.
So you this way you achive a separation between your "client" thread, that just hands over the bytes, and the "remoting" thread that actually performs the non-blocking operations on the channel. This is as "SEDA" as you can get.
Tim wrote :
| It seems to me that our biggest issue is getting an implementation up and running. So far we haven't even got the interface sorted.
|
We will decide on a solution at the end of the remoting meeting that will take place this week. The solution I propose is one of the possible outcomes. Using an external framework it's another. Nothing is a priori overruled.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980596#3980596
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980596
19 years, 5 months
[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:
by bill.burke＠jboss.com
"bill.burke(a)jboss.com" wrote : Found out some things about classloading and URLClassLoader:
|
| * a sun URLClassPath class is used to get .class files as a resource
| * If the URL ends in '/' a "directory" based approach seems to be used and the URLClassPath class concatenates the resource name to the base URL to open the file.
|
| So, when a resource is looked up it will do
|
| vfsfile:/foo.jar/org/jboss/SomeClass.class
|
| to find the resource.
|
| My current guess is that JarFile's are not reentrant nor threadsafe. I took a look at truezip, but it is currently totally based upon java.io.File and a real file system. So you can't just pass in any old URL to get access to the JAR file.
|
|
I'm going to remove the "/" from the end of any JAR vfsfile: URL so that URLClassLoaders will treat the vfsfile: URL as a JAR rather than raw URLs. I couldn't figure out why using raw URLs with the VFS does not work. This leads me to believe we will initially not be able to support an exploded archive nested within an unexploded archive and this will effect things like a WAR's WEB-INF/classes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980595#3980595
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980595
19 years, 5 months
[Design of JBoss Web Services] - Re: Why does DOMWriter copy namespaces?
by jason.greene＠jboss.com
Ah, I see.
I believe the repetition was limited to namespaces defined outside of the content element. This is easy to fix nonetheless.
There is also a problem with qname values. Since only the namespaces that are actually used are declared when needed, and since only elements and attributes are looked at, there is the possibility that a qname element or a qname attribute will not have a defined namespace. JBWS-1303 demonstrates one example of this problem
Further, it is not possible to know if Text nodes or attribute values refer to a qname unless DOMWriter has knowledge of the schema (which is impractical for its purpose). Therefore, the only way to guarantee correct XML is to always copy all namespaces from all parent nodes to the start of a fragment (although using proper scoping).
I implemented this approach in my local tree, but unfortunately the extra namespace noise breaks 20 something tests. This is because the SOAP content element remains in string mode, thus the message is permanently altered. Since this is an undesirable side effect, and since the namespace modified string is only necessary when passing a fragment to an unmarshalling component, the xml string should really be a transient value.
Therefore I see two possible solutions.
1) Modify SOAPContentElement to no longer persist the xml string, and to only use it when unmarshalling is invoked. Also modify SAAJPayloadBuilder to use DOM.
2) Wait for the DOM optimiations (JBWS-1314), and then modify our processing phase to do temporary alterations on the Element before passing to the unmarshaller.
Due to our heavy load, and our tight release schedule, I think we should go with 2. We can then just add workarounds on an as needed basis.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980590#3980590
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980590
19 years, 5 months