[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update
by timfox
"clebert.suconic(a)jboss.com" wrote : I did some work to make sure the LargeMessage sending will be replicated to the backup nodes.
|
| On my initial work, I was having a lot of problems on getting the LargeMessage to be replicated and sent on both nodes. I was aways getting an Out-of-credits on the backup when replicating the message, causing issues on replicating the ACKs and properly failing over to the backup.
|
|
| Changes I had to make to fix the issues on LargeMessage and Failover:
|
| 1) I simple fix to sendLargeMessage
|
|
|
| | On ServerConsumerImpl::
| |
| | private void sendLargeMessage(final MessageReference ref, final ServerMessage message)
| | {
| | // TODO: Should we block until the replication is done?
| | channel.replicatePacket(new SessionReplicateDeliveryMessage(id, message.getMessageID(), message.getDestination()));
| |
| | // SendLargeMessage has to be done on the same thread used on the QueueImpl or we would have problems with ordering and flow control
| | largeMessageSender = new LargeMessageSender((LargeServerMessage)message, ref);
| | largeMessageSender.sendLargeMessage();
| |
| | }
| |
|
|
| This above code used to wait the replication to finish before sending the LargeMessage, what would use another thread. The queue would continue its work asynchronously and the Consumer would eventually handle another message while sendLargeMessage was still processing, what would cause issues on the backup node (not enough credits).
|
When you say "send" I'm assuming you really mean "deliver". (Send means client->server, deliver means server->client). Your usage of send here is confusing.
For non large messages, delivery to the client only occurs when the replication response has come back from the server. If you just do it the same as that, then should be ok?
anonymous wrote :
| 2) When taking credits on backup, we will eventually resume sending the largeMessage.
| That process needs to be done synchronously while receiving the credit from the live node. If we play the commands on a different order we would eventually reject messages because of credit during the replication, or because we would still processing a largeMessage.
|
|
| promptDelivery is now calling resumeLargeMessage if largeMessageSender != null
|
Sorry, didn't understand that explanation.
anonymous wrote :
|
| 3) While receiving LargeMessages, the client will send credits back, as soon as the chunk is received on the client.
| For that handleLargeMessageContinuation, will call flowControl.
|
| While flowcontrol is being called, handleLargeMessageContinuation caller will be holding a lock of the ClientRemoteConsumer.
|
What is ClientRemoteConsumer?
anonymous wrote :
| As a result, we will have a dead lock if failover happens while flowControl is being called within handleLargeMessageContinuation.
|
|
| I am now using an executor for the flowControl, when receiving LargeMessages. This way I release the lock on the ClienteRemoteConsumers while sending the flowcontrol back, so Failover will be able to perform outside of the locks.
|
|
|
|
| All these changes are only applied on https://svn.jboss.org/repos/messaging/branches/Branch_Failover_Page
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201702#4201702
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201702
17 years, 2 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS
by adrian＠jboss.org
"kabir.khan(a)jboss.com" wrote : I have added some failing tests to https://svn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/...
| It mainly seems to be a problem when modules/packages have versions
Yep, I found that myself after I left the office last night.
I won't port your test to the 2.0 branch since I already have my own. ;-)
It was using the wrong findLoader method
i.e. it was doing an importAll=true search all the time
instead of using rules specific to the classloader
| Index: classloader/src/main/java/org/jboss/classloader/spi/base/BaseClassLoader.java
| ===================================================================
| --- classloader/src/main/java/org/jboss/classloader/spi/base/BaseClassLoader.java (revision 82854)
| +++ classloader/src/main/java/org/jboss/classloader/spi/base/BaseClassLoader.java (working copy)
| @@ -370,7 +370,7 @@
| ClassLoaderUtils.checkClassName(className);
| String path = ClassLoaderUtils.classNameToPath(className);
|
| - Loader loader = domain.findLoader(path);
| + Loader loader = domain.findLoader(this, path, basePolicy.isImportAll(), true);
| if (loader == null)
| throw new ClassNotFoundException("Class " + className + " not found from " + this);
|
I've upl,oaded a new 2.0.2-SNAPSHOT with this fix included.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201653#4201653
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201653
17 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: servlet transport implementation
by ataylor
anonymous wrote : What does 'invm' transport refer to here? Do you want Netty to add in-vm transport, or do you want Netty can talk to the in-vm transport that JBM uses internally? The only interfaces that you need to implement is 'ChannelFactory' and 'Channel', so it's not a big deal to implement a bridge between JBM invm transport and Netty. ClientBootstrap should work with any ChannelFactory implementation.
By invm transport I mean rather than writing to a socket channel use an invm channel and pass the buffers directly thus avoiding the latency Tim was talking about. I guess you've answered my question there isn't. So I guess I need to provide a new implementation of ChannelFactory and Channel which can do this?
anonymous wrote : I think Netty needs to provide a cookie encoder / decoder as we did for query strings.
Ok, this should be pretty simple.
anonymous wrote : I understood how it works, but out of curiosity, why does the Servlet need to talk to JBM via Netty? Isn't it just enough for the Servlet to talk to JBM directly? Perhaps I am missing out something.
No, JBM will only receive the http response, it won't talk to netty.
anonymous wrote : It could be distributed as a separate WAR, hence we could create a subproject under svn.jboss.org/repos/netty/subproject/servlet (or some cool name :-)
Ok, that will give it seperation and make it easier to deploy. what would you like to call the sub project?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201649#4201649
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201649
17 years, 2 months