[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover on Shutdown
by timfox
The main problem with the suggestion is the following:
In JBM each node maintains its own set of "partial queues". So if you have a distributed queue A, for example, deployed across the cluster, then A is actually made up of a set of n queues (n = number of nodes in cluster), each node maintaining its own queue.
So, in normal cluster operation, each partial queue will have its own set of messages in it.
On failover, another node in the cluster takes over the partial queues of the failed node and merges them into its own set of queues. We need to do this so the client can transparently carry on its session on the new node, e.g. it needs to know about messages it has consumed but not acked so they can subsequently be acked on the new node.
Shutting down a node in the cluster is quite different from failing over. With a shutdown, it is likely the sys admin is just taking the node down temporarily and will restart it again shortly. In this case we *do not* want another node to take over and merge the queues of the node that is being taken down.
Imagine the pathological case where the sysadmin takes every node in the cluster down one by one. By the time the sysadmin takes down the last node in the cluster, that node will have merged in *all* the queues from the other nodes! Not only will this be slow, but it means that when the cluster is brought back up, only one of the nodes (the last one to be taken down) will have all the messages.
This is obviously not something we want.
Another question we should ask is "is it possible to trigger the client side failover without triggering the server side failover?" - i.e. could we fail over the clients on shutdown without failing over the server side (i.e. merging queues)?
The answer to this is also no, since we would then lose transparent failover, since if we failed over a client which has unacked messages in its session then it would fail to ack them on the failover node since the queues hadn't been merged.
So in summary, it seems pretty clear to me that forcing failover on shutdown is not going to work with transparent failover.
However, nne thing we could maybe do is introduce a "JBoss MQ style mode", where we disable automatic failover on the server side - so if a server node fails then its queues are *not* merged into another nodes queues.
Client side automatic failover can already be disabled by setting "supportsFailover" to false on the connection factory.
By doing so, a client application could just catch the exception thrown to a connection ExceptionListener and re-lookup the connection factory using HAJNDI and recreate the connection etc, a la JBoss MQ. This would work but is it means none of the automatic failover functionality would be used, which seems a shame to me.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053193#4053193
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053193
19 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
by timfox
"sergeypk"
a) the HTTP invoker is configured differently from socket-based invokers. If we are to configure the HTTP invoker from XML as well, should remoting-service.xml then be split into remoting-service-http.xml and remoting-service-bisocket.xml? Or should remoting-service.xml contain settings for both invokers?
[/quote wrote :
|
| Ideally we should maintain a directory somewhere which has a remoting-service-http.xml and remoting-service-bisocket.xml and remoting-service-sslbisocket.xml in it.
|
| The test framework should then choose one of these based upon the test config.
|
| The same config should also be used when building the sar file and by the examples, since we don't want to duplicate the config anywhere.
|
| anonymous wrote :
| | b) Should the bisocket configuration be shared among other socket-based invokers (socket, sslsocket, sslbisocket), or should I add a separate file for each of the invokers, thus duplicating the common settings?
| |
|
| See above.
|
| Actually we only support http, bisocket and sslbisocket in JBM so don't worry about the others, but the ones we DO support should be in their own file.
|
| anonymous wrote :
| | c) The way I've implemented this is I load remoting-service.xml, get hold of the configuration, fetch all attributes with isParam set and combine their keys and values to form the URL, since as far as I understand, the URL should only contain those attributes marked with isParam=true. However, serverSocketClass was originally included in the URL even though it is not marked with isParam. Is this the way it should be or is this an oversight?
|
| I don't understand why you are generating a locator URI, this should be unnecessary.
|
| You just need to deploy the remoting connector service from the xml. Certainly there should be no need to parse the xml and manually create a URI.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053186#4053186
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053186
19 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remote replyto functionality - Bridge configuration in p
by timfox
Interestintg ideas, some thoughts:
Regading the correlation id approach, wo we really need to automatically correlate message ids from server 1 with message ids from server 2?
One other possibility would be for the JBM bridge to take the old message id (the message id before sending to the second server) and set it is a property of the message (with a key JBossMessage.JBM_OLD_MESSAGE_ID (or whatever)).
The receiver of the message on the second server then has access to this property and can set it as the JMSCorrelationID of the response message. This would avoid the bridge having to maintain its own lookup map.
The JBM_OLD_MESSAGE_ID could even be chained, if the message has been routed through several servers before arriving at its destination, so it would actually be a set of message ids.
Regarding the temporary queue approach, yes this could work and is quite a nice idea. However, the tricky bit would knowing whether you'd already created a temporary queue on the remote server for a particular message, since you don't want to create a new temp queue on *every* message send, with a temp queue request/response model you typicall use the same remote queue for the whole sender's session. Also we would need to know when it is safe to delete the remote temp queue - this might be tricky too.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053177#4053177
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053177
19 years
[Design of JBoss jBPM] - Re: Thinking about transition attrs
by brittm
re: "confirm='true'"
anonymous wrote : that is UI. the task form ui only can do so much. we can keep adding features till it is as rich as JSF+Facelets+RichFaces... if it would be added, it should be done in the Facelets form document.
The problem here is that it is not up to the UI designer to determine what should require a confirmation. This is the domain of business analyst/process designer.
We have nearly 200 tasks over more than 20 processes (and we're not done). We work in a rapidly evolving environment and need a way to tell the UI developer which transitions need a confirmation based on their impact on the process--some way other than handing him a spreadsheet of 100+ process/node/transition combinations to keep track of.
To keep things sane we'll either have to break with schema valid jpdl, or use a naming convention--something like if the transition name starts with a "+", don't display the "+" and require a confirmation.
The same thing is true with restricted access. We're already blocking visibility of transitions like 'administrative cancel' and 'retry integration' by prefixing them with an "_". Its a way to say "admin only" without having to know how the UIs define that role.
But parsing transition names to figure out which type they are is a poor solution. Sure, we can build our own configuration files/tables to sit along side of jBPM, but then we're just repeating 'process/node/transition' mappings over and over, and are operating outside the scope of versioning.
Both of these items are configuration flags that specify how a transition should behave, not how that behavior should be implemented.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053167#4053167
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053167
19 years