[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover
by timfox
"clebert.suconic(a)jboss.com" wrote : Just for reference, this method from DefaultClusteredPostOffice is going to be the heart of serverSide failover:
|
|
| | public void failOver(int nodeId) throws Exception
| | {
| | log.info("Preparing failover against node " + nodeId);
| | Map subMaps = (Map)nameMaps.get(new Integer(nodeId));
| | ArrayList namesToRemove = new ArrayList();
| | for (Iterator iterNames = subMaps.entrySet().iterator();iterNames.hasNext();)
| | {
| | Map.Entry entry = (Map.Entry)iterNames.next();
| | Binding binding = (Binding )entry.getValue();
| | if (binding.getQueue().isClustered())
| | {
| | ClusteredQueue queue = (ClusteredQueue) binding.getQueue();
| | if (!queue.isLocal())
| |
|
There should be no need to check if the queue is clustered and not local, they will *always* be clustered and not local in the name map for a remote node, so this is redundant.
"clebert" wrote :
|
| |
| | {
| | namesToRemove.add(entry);
| | }
| | }
| | }
| |
| | for (Iterator iterNames = namesToRemove.iterator();iterNames.hasNext();)
| | {
| | Map.Entry entry = (Map.Entry)iterNames.next();
| | DefaultBinding binding = (DefaultBinding)entry.getValue();
| |
|
The correct type is Binding, not DefaultBinding?
"clebert" wrote :
|
| | RemoteQueueStub stub = (RemoteQueueStub)binding.getQueue();
| | this.removeBinding(nodeId,(String)entry.getKey());
| |
|
The remove needs to be broadcast across the cluster so other nodes can remove the binding too
"clebert" wrote :
|
| | Binding newBinding = this.createBinding(this.nodeId,nodeId,binding.getCondition(),stub.getName(),stub.getChannelID(),stub.getFilter(),stub.isRecoverable());
| | LocalClusteredQueue clusteredQueue = (LocalClusteredQueue )newBinding.getQueue();
| | clusteredQueue.deactivate();
| | clusteredQueue.load();
| | clusteredQueue.activate();
| | addBinding(newBinding);
| |
|
Isn't there going to be a problem creating two bindings with the same name?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981969#3981969
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981969
19 years, 1 month
[Design of JBoss Collaboration Server] - Problem sending to remote sites
by enazareno
Hello,
I am setting up JBCS 1.04 final for production use. My basic requirement is sending email alerts to remote sites like Yahoo and Hotmail, etc (NOT for spamming). The server is running on Linux Fedora. My DB is MySQL 5.0. In our development, there seems to be no problem. However, when I set it up in production (which is a different site btw), there is no guarantee that the mail arrives. I always get the mail is deferred error, but sometimes it is sent successfully. Most of the time it does not. I am quite a newbie to setting up my own email server, and I don't know which to go. How do I check for the logs? We have setup our DNS, and provided some MX entries. Are we not configuring it correctly, Is it the network or is it something blocking our emails. I would appreciate if somebody can show me the light.
Another observation. If I send email the first time, it does not arrive. When I successively send emails of the same address, the first ones in the queue seems to get delivered. But I am not sure if this is a conclusive observation since I am only sending to Yahoo. Is there a known bug like this or is it an anti-spamming thing? Thanks
Regards,
Elmo
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981968#3981968
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981968
19 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover
by timfox
A few comments:
"clebert.suconic(a)jboss.com" wrote : I have committed some changes regarding server side failover.
|
| In summary, these changes consist of:
|
| I - Method failover(int) on DefaultClusteredPostOffice..
| Still not integrated on JGroups:viewsChange, but that it's a trivial change (I hope). I will integrate it after I have done some more testing
|
No need for the method to public - it will only be called from inside the post office
"clebert" wrote :
| II - Signature changes on PostOffice/ClusteredPostOffice to accept bindinging from other nodeIds than the current NodeId.
|
If the failover is driven from inside the postoffice then shouldn't need this on the interface?
"clebert" wrote :
| Also... It looks like we will have to send messages received from client to server. This is because we will need to remove references on the database. I'm still investigating as I'm seeing messages still on the database after being received.
|
Doesn't sound right to me. I'll have a look at the code.
"clebert" wrote :
| I will solve the messageId problems by tomorrow for sure, so I'm fine with this, it's just a matter of getting the job done.
|
Great. Seems like you're making good progress :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981967#3981967
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981967
19 years, 1 month
[Design of POJO Server] - WarDeployer dependency on TomcatClusteringCache
by bstansberry＠jboss.com
I've commented out the dependency of the WarDeployer on the TomcatClusteringCache as it was preventing the start of the 'all' config. This thread is to discuss how to restore the relevant dependencies.
I expect this was failing because a bean loaded via the VFSDeployerScanner can't depend on a bean subsequently loaded via the VFSDeploymentScanner.
The dependency arises from two causes:
1) If ClusteredSSO is used, the embedded Tomcat itself depends on the TomcatClusteringCache. The ClusteredSSO valve actually looks up the cache though based on an injected object name, and has some ill-considered code where it won't fail on start if the cache isn't there but rather waits to find it when it needs to service a request. So, expressing the dependency in the WarDeployer isn't strictly necessary, although removing it is hacky.
2) Distributable webapps need the cache for their sessions. This seems more straightforward -- it's the deployment that has the dependency, not the deployer. The WarDeployer should be able to add a dependency on the cache to any distributable webapp as part of the deployment process. It just needs to know the object name of the cache.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981961#3981961
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981961
19 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover
by clebert.suconic＠jboss.com
Just for reference, this method from DefaultClusteredPostOffice is going to be the heart of serverSide failover:
| public void failOver(int nodeId) throws Exception
| {
| log.info("Preparing failover against node " + nodeId);
| Map subMaps = (Map)nameMaps.get(new Integer(nodeId));
| ArrayList namesToRemove = new ArrayList();
| for (Iterator iterNames = subMaps.entrySet().iterator();iterNames.hasNext();)
| {
| Map.Entry entry = (Map.Entry)iterNames.next();
| Binding binding = (Binding )entry.getValue();
| if (binding.getQueue().isClustered())
| {
| ClusteredQueue queue = (ClusteredQueue) binding.getQueue();
| if (!queue.isLocal())
| {
| namesToRemove.add(entry);
| }
| }
| }
|
| for (Iterator iterNames = namesToRemove.iterator();iterNames.hasNext();)
| {
| Map.Entry entry = (Map.Entry)iterNames.next();
| DefaultBinding binding = (DefaultBinding)entry.getValue();
| RemoteQueueStub stub = (RemoteQueueStub)binding.getQueue();
| this.removeBinding(nodeId,(String)entry.getKey());
|
| Binding newBinding = this.createBinding(this.nodeId,nodeId,binding.getCondition(),stub.getName(),stub.getChannelID(),stub.getFilter(),stub.isRecoverable());
| LocalClusteredQueue clusteredQueue = (LocalClusteredQueue )newBinding.getQueue();
| clusteredQueue.deactivate();
| clusteredQueue.load();
| clusteredQueue.activate();
| addBinding(newBinding);
| }
| }
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981951#3981951
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981951
19 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover
by clebert.suconic＠jboss.com
I have committed some changes regarding server side failover.
In summary, these changes consist of:
I - Method failover(int) on DefaultClusteredPostOffice..
Still not integrated on JGroups:viewsChange, but that it's a trivial change (I hope). I will integrate it after I have done some more testing
II - Signature changes on PostOffice/ClusteredPostOffice to accept bindinging from other nodeIds than the current NodeId.
III - Changes on DefaultRouter to accept more than one local queue (created when DefaultClusteredPostOffice.failover is caleld).
Also... It looks like we will have to send messages received from client to server. This is because we will need to remove references on the database. I'm still investigating as I'm seeing messages still on the database after being received.
Also, you will realize a couple of TODOs on the code that are there just for tests. For example I'm ignoring some exceptions if a ACK is not found. This is just a temporary solution until I figure out what to do with pre-received messageIds. (send, ignore them, or find what's going on sometimes).
I will solve the messageId problems by tomorrow for sure, so I'm fine with this, it's just a matter of getting the job done.
Cheers,
Clebert Suconic
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981949#3981949
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981949
19 years, 1 month
[Design of JBoss jBPM] - Enterprise subproject and EJB spec level
by jeffdelong
Tom,
I was looking over the enterprise subproject and noticing that the EJB are "old-school" EJB2 beans. I think that given JBoss leadership in EJB3, we should consider updating these beans to EJB3. We can use annotations, and get rid of the ejb-jar.xml files as well.
Also there is a comment in CommandListenerBean,
} catch (Exception e) {
e.printStackTrace();
// TODO add a retry mechanism or verify how this can be configured in the MDB itself
throw new JbpmException("command "+command+" couldn't be executed", e);
}
If the bean is deployed with transaction-attribute required (which is the default), then the container should automatically rollback the transaction if a system exception is thrown, which will cause the JMS Server to retry the message for some configurable number of tries, and then place the message on the DLQ.
You can also catch non-system exception (e.g., an ObjectNotFoundException, InvalidStateException, etc), and invoke setRollbackOnly on the messageDrivenContext, i.e.,
messageDrivenContext.setRollbackOnly();
Jeff
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981947#3981947
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981947
19 years, 1 month