[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging
by ron_sigal
"ovidiu wrote :
| "Ron" wrote :
| |
| | (a) push callbacks: a Connector (complete with ServerSocket) is created on the client side, and calling ServerInvokerCallbackHandler.handleCallback() causes an invocation to be made from server side to client side.
| |
| |
| | Not an option. Or not anymore, at this stage. The socket transport will be rendered irrelevant soon, one way or another, so we don't want to waste any more time on that. See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979236 If it currently works with the socket transport, that's good, but we need to get the multiplex transport working ASAP.
| |
|
The polling style of callbacks will work just as well with the socket transport, which as I mention on http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979219
is an alternative to the multiplex transport.
"ovidiu" wrote :
| Yes, but no disk. For non persistent messages we don't care anyway, and for persistent messages, they're already stored by the channel, so we're covered. Disk at that level can only slow down things. Obviously this can be configured. Right?
|
Actually, Tom wrote a "callback store" which blocks instead of writing to disk when it's running out of heap. I think that was done at Tim's request. It can be specified with the Connector configuration
"ovidiu" wrote :
|
| Ron wrote:
|
| In order to replace invocations with callbacks, a callback acknowledgement facility was added to Remoting. When ServerConsumerEndpoint.Deliverer sends a callback, it also stores the callback in a pendingCallbacks HashSet, from which it is removed upon acknowledgement.
|
|
| According to Tim, we don't need that. Sending the message from server to client should be fully asynchronous, so we don't need acknowledgments.
|
The first real problem I ran up against in Messaging was that sometimes ServerConsumerEndpoint.stop() would return before the client side had a chance to acknowledge all of its delivered messages. I put in acknowledgements to prevent that problem. Now, stop() waits until all outstanding deliveries have been handed over to the MessageCallbackHandler. This duplicates the earlier behavior when callbacks were handled explicitly by Messaging.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979285#3979285
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979285
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Multiplexed (Bidirectional) Transport
by ron_sigal
1. There is another solution to the firewall problem.
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
|
Tom implemented a polling callback mechanism [I think it was requested by the Messaging group] which simulates the use of a callback server on the client side. I've used it on the Branch_HTTP_Experiment Messaging branch to avoid client side server sockets with the HTTP transport, but it would work with the socket transport as well. There's some latency according to the (configurable) polling frequency, but it also has the advantage of bundling up all pending callbacks in a single transmission.
2. I'm not sure what a bidirectional channel would look like in Remoting, but there's a sense in which Remoting connections are close to a bidirectional channel. From client to server, there's the option of an invocation which is asynchronous at the application level, i.e., it returns immediately, and with the NIO transport it will be asynchronous at the transport level. From server to client, callbacks are not too conceptually different from asynchronous invocations. A payload is passed to Remoting and on the other side it lands on an application level handler. It may not be as elegant as a bidirectional channel, but I'd guess performance trumps elegance right now. And I'd say that Tim has done a pretty virtuoso job of working with the materials at hand.
3. As for the performance of the current multiplex transport, the only honest answer I can give is that I don't know how much better it can be. I went through one round of optimization a few months ago, but in the absence of customers it wasn't clearly productive to keep squeezing. There is certainly overhead in lifecycle operations, but the real issue is pushing bytes on the network. I don't think the presence of virtual sockets is really a problem - there's a lot of code there that makes them look like real sockets but isn't in the line of fire most of the time. If there's room for improvement, I think it must be at the layer below virtual sockets. Right now a VirtualSocket.write() operation leaves some bytes on a queue, from which they are retrieved by another thread which writes them to the actual socket. The point was to allow the write() to return without waiting for the network i/o to finish. But in the optimization phase I switched to NIO sockets (except for SSL connections), so that issue is moot, and maybe there's some improvement to be gained by directly accessing the socket.
It does seem to me that, in terms of i/o, virtual sockets shouldn't be significantly slower than real sockets. I'd be happy to have another go at it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979282#3979282
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979282
19 years, 5 months
[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()
by scott.stark＠jboss.org
This is a problem because some jars are not being recognized because they only have a META-INF/MANIFEST entry (no META-INF dir entry) and are not being added to the deployment classpath because the JarStructure test for a META-INF entry is failing. The jbossws.sar/wsdl4j.jar is another example that causes this NCDFE:
Caused by: java.lang.NoClassDefFoundError: javax/wsdl/WSDLException
at jrockit.reflect.InitialConstructorInvoker.newInstance([Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at java.lang.reflect.Constructor.newInstance([Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source)
at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1242)
at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286)
at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:3
Looks like some synthentic parent entries will be needed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979258#3979258
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979258
19 years, 5 months
[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()
by scott.stark＠jboss.org
While testing this against jboss-head I ran into some unusual jars that don't have all the directory entries:
| [starksm@succubus JBossMC]$ jar -tf /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta/server/default/lib/jpl-util.jar
| META-INF/MANIFEST.MF
| org/gjt/lindfors/util/BoundBuffer$1.class
| org/gjt/lindfors/util/BoundBuffer.class
| org/gjt/lindfors/util/EventGenerator.class
| org/gjt/lindfors/util/EventGeneratorSupport$1.class
| org/gjt/lindfors/util/EventGeneratorSupport.class
| org/gjt/lindfors/util/Library.class
| org/gjt/lindfors/util/LocalizationSupport$1.class
| org/gjt/lindfors/util/LocalizationSupport.class
| org/gjt/lindfors/util/Pair.class
| org/gjt/lindfors/util/PluggableVisualizer.class
| org/gjt/lindfors/util/strategy/VisualizerStrategy.class
| org/gjt/lindfors/util/StreamReaderThread.class
| org/gjt/lindfors/util/support/VisualizerSupport.class
| org/gjt/lindfors/util/Trace.class
| org/gjt/lindfors/util/TypeSupport.class
| org/gjt/lindfors/util/Visualizable.class
| org/
| org/gjt/
| org/gjt/lindfors/
| org/gjt/lindfors/gui/
| org/gjt/lindfors/gui/AboutDialog$CloseDialogAction.class
| org/gjt/lindfors/gui/AboutDialog.class
|
a quick workaround is just to add these to the parent jar handler, but I'm not sure if this is going to work with the structured file handler logic. I'm testing this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979252#3979252
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979252
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Ability to send unformatted data
by tom.elrod＠jboss.com
anonymous wrote :
| 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.
|
Actually, remoting servers can identify if receiving requests from non-remoting clients and still continue to process request. Is also possible for remoting clients to send requests to non-remoting servers (just needs raw config when doing invocation). For example, have tests for http client invoker that calls on web services on the internet written with .Net and can use http server invoker as web server to Firefox browser. Also have socket client test (org.jboss.test.remoting.transport.socket.raw.RawTestClient) that makes raw socket request to socket server invoker (however, does require use of object stream instead of raw stream which will be fixed per http://jira.jboss.com/jira/browse/JBREM-597).
So I think it would be *possible* to accept and send AMQP frames via remoting, but would be so difficult with current API that if anyone tried it, they would go mad (I mean The Shining kind of mad).
The ongoing thread at http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979239#3979239 covers what would be a better approach within remoting in this regard.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979247#3979247
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979247
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging
by ovidiu.feodorov＠jboss.com
Ron wrote :
| I. The central change has been to push callbacks back down into the Remoting layer. In particular, where on HEAD ServerConsumerEndpoint.Deliverer gets the ServerInvokerCallbackHandler's Client and delivers messages to the client side using Client.invoke(), on the HTTP branch it calls ServerInvokerCallbackHandler.handleCallback(). As a result, Messaging can take advantage of Remoting's variety of callback options.
|
That's good. Using the callback abstraction correctly is the right way to go.
Ron wrote :
| (a) push callbacks: a Connector (complete with ServerSocket) is created on the client side, and calling ServerInvokerCallbackHandler.handleCallback() causes an invocation to be made from server side to client side.
|
Not an option. Or not anymore, at this stage. The socket transport will be rendered irrelevant soon, one way or another, so we don't want to waste any more time on that. See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979236 If it currently works with the socket transport, that's good, but we need to get the multiplex transport working ASAP.
Ron wrote :
| (b) poll callbacks: calling ServerInvokerCallbackHandler.handleCallback() causes the callback to be stored (possibly on disk) until the client side polls for pending callbacks. No ServerSocket is created on the client side.
|
Yes, but no disk. For non persistent messages we don't care anyway, and for persistent messages, they're already stored by the channel, so we're covered. Disk at that level can only slow down things. Obviously this can be configured. Right?
Ron wrote :
| In order to replace invocations with callbacks, a callback acknowledgement facility was added to Remoting. When ServerConsumerEndpoint.Deliverer sends a callback, it also stores the callback in a pendingCallbacks HashSet, from which it is removed upon acknowledgement.
|
According to Tim, we don't need that. Sending the message from server to client should be fully asynchronous, so we don't need acknowledgments. More on this here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=92954. Care to comment, Tim?
Ron wrote :
| II. The new Messaging specific serialization structure interacts with callbacks to generate some added complexity in JMSWireFormat. Because of the two forms of callbacks, there are two delivery modes for callbacks, and each has to be unwound to expose the ClientDelivery. For example, callback polling delivers an ArrayList of pending callbacks, and each ClientDelivery in the list has to be processed separately. There's also another related issue. In pull or poll mode, callbacks are stored on the server, which might involve writing them to secondary storage. Currently, the application's designated serialization type determines how the callbacks are transferred to and from disk, but MessagingObjectInputStream and MessagingObjectOutputStream are derived from the standard java classes, which can't handle Messaging non-Serializable messages. For now I've worked around the problem in my local version of Remoting, but the problem still needs to be resolved. Is there any reason the Messaging can't use JBoss Serialization?
|
You lost me here. I'll look tomorrow at the code.
Ron wrote :
| IV. Right now the HTTP branch runs with my own private version of Remoting. I've checked in a copy of jboss-remoting.jar in the lib directory.
|
Good. As soon as we agree on changes, I would asume that Tom can release an Alpha (or Beta) so we can pick the jar from repository.
Ron wrote :
| V. It's 4am and right now it looks like everything's broken. Great. Well, it WAS working.
|
It will work again :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979243#3979243
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979243
19 years, 5 months