[JBoss-user] [JCA/JBoss] - Re: JBossWorkManager waitForAll()
Hi, thanks for your reply. I had already feared that this is not part of the JCA spec.. I will submit it as a feature request. Thanks :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3933600#3933600 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3933600 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [JCA/JBoss] - JBossWorkManager waitForAll()
Hi, I wonder if the JBossWorkManager provides an easy way to start several synchronous threads and wait for all of them to finish. I can vaguely remember I saw other WorkManager implementations which had a waitForAll(jobs..) method.. but I cant find such a method in the JBossWorkManager.. does a similar method exist, which accomplishes the same thing? Thanks for your time. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3933277#3933277 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3933277 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Beginners Corner] - Re: How to get a WorkManager from a Bean
Hi, I know your post was a long time ago. I was asking myself the same Question today, and I could not find a simple example of this..so it took me a rather long time to come up with a solution..I thought it could not hurt to post it here... | //get MBean Server | MBeanServer server = MBeanServerLocator.locateJBoss(); | | //get WorkManager | ObjectName objectName = new ObjectName(jboss.jca:service=WorkManager); | JBossWorkManagerMBean jwm = (JBossWorkManagerMBean) | MBeanServerInvocationHandler.newProxyInstance(server,objectName,JBossWorkManagerMBean.class,false); | WorkManager wm = jwm.getInstance(); | | //schedule Work for Execution | wm.scheduleWork(new SomeWork()); | Note that there is a difference between scheduleWork() (call returns immediately) doWork(call returns when work is finished) and startWork() (call returns when work is started). Btw. If there is anything wrong with this solution, I would appreciate it if someone could tell me. TIA :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3932768#3932768 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3932768 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
[EMAIL PROTECTED] wrote : This has to be a side-effect of farming. Instead of farming the deployments, just deployment them to the servers and rerun the test. Farming has to be propagating the undeployment event to all nodes. This is not what the ProxyFactoryHA state listener was designed for. | I have now disabled farming on all nodes. I use the original ProxyFactoryHA again, and deploy the MBean manually. The odd behavior is still there. As soon as I undeploy the MBean on one node (delete .sar file from deploy directory) the MBean.STOPPING event is propagated to all replicants -- the containerIsAboutToStop() method gets called on every replicant -- they all disappear from the DistributedReplicantManager's listContent() view.. so my guess is that it has nothing to do with farming. I would love to investigate further on this, as this has really sparked my interest, but unfortunately I have already spent more time on the MBean clustering than I was supposed to.. and the patch I posted above works fine for me.. so I think I'll just open a JIRA issue with the detailed behavior as soon as I find the time. Thank you very much for your replies everybody. It's good to see that the devs are active in the forums and actually give valuable feedback to user questions. :-) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3928139#3928139 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3928139 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
[EMAIL PROTECTED] wrote : DistributedReplicantManager.remove does not remove all values for the given key. It just removes the value associated with the key. | Yes you are correct. I tested the remove's behavior in the JMX console today and it does what it is supposed to do. My bad. Still the patch I posted yesterday solved my problem and I was curious why, so I played around some more... as soon as a target.destroy() appears in the containerIsAboutToStop() method, the behavior I described occurs... The problem with this is the following: the containerIsAboutToStop() method gets called from the StateChangeListener. When one Replicant is undeployed (for whatever reason) this method is called. But not only for the Replicant which is going down, but for ALL the replicants (they all registered a listener after all). And consecutively every replicant thinks itself is about to stop and disables itself. Now that was a tough one. :-) I guess thats the core reason for the behavior I have been noticing the last few days. Should not be so hard to fix, the ProxyFactoryHA just has to check if the ServiceMBean.STOPPING event was meant for itself or a different replica. [EMAIL PROTECTED] wrote : | The behavior you describe does not occur when shutting down a node with clustered ejbs, so something does not seem correct with the usage. | This is just a guess, but I think this behavior does not occur with ejbs because they never recieve ServiceMBean.STOPPING events? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927385#3927385 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927385 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Hmm I have clustered a simple test MBean class at the moment it is called
WorkflowControllerServiceMBean:
| public interface WorkflowControllerServiceMBean extends HAMBean {
|public void test();
| }
|
I extracted the invoke() Method to a separate interface called HAMBean:
| import org.jboss.system.ServiceMBean;
|
| public interface HAMBean extends ServiceMBean {
| public Object invoke(Invocation invocation) throws Exception;
| }
|
The implementation of the WorkflowControllerService just outputs some string to
the console.
| public class WorkflowControllerService
| extends AbstractHAMBean implements WorkflowControllerServiceMBean {
|
|
| public void test() {
| System.out.println(TEST TEST TESTTEST TEST TESTTEST TEST
TESTTEST TEST TEST);
| }
|
The AbstractHAMBean class the WorkflowController extends contains the methods
for setting up the method hashes and registering the service name hash in the
Registry. It is more or less a copy and paste from
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/src/main/org/jboss/test/jmx/ha/HAService.java?rev=1.2.6.1view=markup
| import org.jboss.ha.jmx.HAServiceMBeanSupport;
|
| public class AbstractHAMBean extends HAServiceMBeanSupport implements
HAMBean {
|
| protected Map marshalledInvocationMapping = null;
|
| public void startService() throws Exception {
| super.startService();
| log.info(Calculating Method Hashes for + serviceName);
| Class[] ifs = this.getClass().getInterfaces();
| HashMapLong,Method tmpMap = new HashMapLong,Method();
| for (Class i : ifs) {
| log.info(Adding Methods Interface: + i.getName());
| // Calulate method hashes for remote invocation
| Method[] methods = i.getMethods();
| for (int m = 0; m methods.length; m++) {
| Method method = methods[m];
| Long hash = new
Long(MarshalledInvocation.calculateHash(method));
| //log.info(Adding Method: +
method.getName());
| tmpMap.put(hash, method);
| }
| }
|
| Registry.bind(new Integer(serviceName.hashCode()), serviceName);
| marshalledInvocationMapping =
Collections.unmodifiableMap(tmpMap);
|
| log.info(Started MBean: + serviceName);
| }
|
| public void stopService() throws Exception {
| super.stopService();
| Registry.unbind(new Integer(serviceName.hashCode()));
| log.info(Stopped MBean: + serviceName);
| }
|
| /**
| * This is the remote entry point
| */
| public Object invoke(Invocation invocation) throws Exception {
| // Invoked remotely, inject method resolution
| if (invocation instanceof MarshalledInvocation) {
| MarshalledInvocation mi = (MarshalledInvocation)
invocation;
| mi.setMethodMap(marshalledInvocationMapping);
| }
| Method method = invocation.getMethod();
| Object[] args = invocation.getArguments();
|
| // Setup any security context (only useful if something checks
it, this
| // impl doesn't)
| Principal principal = invocation.getPrincipal();
| Object credential = invocation.getCredential();
| SecurityAssociation.setPrincipal(principal);
| SecurityAssociation.setCredential(credential);
|
| // Dispatch the invocation
| try {
| return method.invoke(this, args);
| } catch (InvocationTargetException e) {
| Throwable t = e.getTargetException();
| if (t instanceof Exception) {
| throw (Exception) t;
| } else {
| throw new UndeclaredThrowableException(t,
method.toString());
| }
| } finally {
| // Clear the security context
| SecurityAssociation.clear();
| }
| }
|
| }
|
The associated jboss-service.xml looks like this:
| ?xml version=1.0 encoding=UTF-8?
|
| server
|
|!-- Create JRMPHA proxy for our service --
|mbean code=org.jboss.proxy.generic.ProxyFactoryHA
name=arsenal.at:service=ProxyFactoryHA,name=WorkflowControllerFactory,protocol=jrmpha
| !-- Use the default partition --
| depends
optional-attribute-name=PartitionObjectNamejboss:service=DefaultPartition/depends
|
| !-- Use the standard JRMPInvoker
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Thanks for your reply. I have turned on TRACE as you suggested, and found out the following: This is a line from my logs when the Invocations work as expected (deployed to two nodes via farming): | 2006-03-01 09:18:19,678 TRACE [org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA] Init, clusterInfo: [EMAIL PROTECTED]/arsenal.at:service=WorkflowController/H,targets=[JRMPInvoker_Stub[UnicastRef2 [liveRef: [endpoint:[192.168.0.10:4447](remote),objID:[4b46ef39:109b4b3c025:-8000, 2, JRMPInvoker_Stub[UnicastRef2 [liveRef: [endpoint:[192.168.0.12:4447](remote),objID:[-40e2315:109b4e0dbe2:-8000, 2],currentViewId=-243866888,isViewMembersInSyncWithViewId=true,cursor=1,arbitraryObject=null}, [EMAIL PROTECTED] | Notice the two liveRefs that are present in the targets[]. Everything works fine... As soon as I shut down one node the same trace looks like this: | 2006-03-01 09:20:12,082 TRACE [org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA] Init, clusterInfo: [EMAIL PROTECTED]/arsenal.at:service=WorkflowController/H,targets=[],currentViewId=0,isViewMembersInSyncWithViewId=true,cursor=1,arbitraryObject=null}, [EMAIL PROTECTED] | _Both_ liveRefs have vanished and targets[] is emtpy, which explains the ServiceUnavailableException, as you expected. So it boils down to this question: Why are both liveRefs removed when I shut down one node? (As I am absolutely new to this, it is highly probable that I am making some kind of obvious mistake, which I am overlooking..) Thanks for helping :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927021#3927021 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927021 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Ok to further illustrate this behavior I have played around with the jmx console. The DistributedReplicantManager of the DefaultPartition has a listContent() method which displays the availibility of services in the cluster partition. My setup is as follows, I have the service (WorkflowControllerService) deployed on two nodes: 192.168.0.10 and 192.168.0.12 ... On a third node I invoke the listContent() method on the local DistributedReplicantManager.. the following happens * start all three nodes * deploy WorkflowControllerService on 192.168.0.10 and 192.168.0.12 with farming * start up jmx console on 192.168.0.11 (the third node) and invoke listContent() | --- | Service : HAJNDI | | - Service *is* also available locally | - 192.168.0.10:1099 | - 192.168.0.12:1099 | | --- | Service : arsenal.at:service=WorkflowController | | - Service is *not* available locally | - 192.168.0.10:1099 | - 192.168.0.12:1099 | | --- | Service : DCacheBridge-DefaultJGBridge | | - Service *is* also available locally | - 192.168.0.10:1099 | - 192.168.0.12:1099 | Ok thats what I expected to see... At this stage the LoadBalanced invocations work fine... but now.. * Kill Node 192.168.0.12 (ctrl+c) .. or the other one it does not matter I have tried it with both.. * invoke listContent() on 192.168.0.11 | --- | Service : HAJNDI | | - Service *is* also available locally | - 192.168.0.10:1099 | | --- | Service : DCacheBridge-DefaultJGBridge | | - Service *is* also available locally | - 192.168.0.10:1099 | There! Both of the WorkflowController Instances are gone... I would expect the Instance on 192.168.0.10 to be still here. The funny thing is, if I do not shutdown the whole server but only use the stop() and destroy() methods of the associated ProxyFactoryHA on node 192.168.0.10 then it works as expected: -- The output of listContents() then shows the remaining Instance of the WorkflowController on 192.168.0.12 and everything works well. -- I can even restart the ProxyFactoryHA by using create() and start(), then listContent() displays it again, and Invocations are again RoundRobin scheduled as I would expect them to be. But as soon as I shutdown one node completely it breaks everything, and I can only get it to work again by manually undeploying the service from the farm (delete the .sar from the /farm directory) and then redeploying the service. Awfully long post, sorry about that. But I am really not sure what to make of this :/ View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927060#3927060 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927060 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Me again... :) I managed to narrow down the area where things go wrong: Undeployment. When a node is shut down with ctrl+c JBoss undeploys all the MBeans. Naturally it also undeploys my custom MBean. What seems to go wrong here is that when it undeploys the ProyxFaxtoryHA it does not only remove the one instance of the service from the DistributedReplicantManager but rather it removes them all.. Why do I believe this? I tried to put a sleep() command in the stop() method of my MBean so I had time to reload the listContent() view of the DistributedReplicantManager while the MBean was being undeployed. I discovered that _all_ instances of the arsenal.at:service=WorkflowController disappear as soon as the _first_ cluster node starts to undeploy the MBean (since the ProxyFactoryHA depends on that MBean I assume that it is removed before the stop() method on my MBean is called, and the sleep() gives me time to reload the view)... Consequently I tested a node failure by pulling the network cable on one of the nodes.. and it _worked_ .. the cluster discovered the dead member.. the view in listContent() lost only the service instance of the failed node. All subsequent invocations were passed to the living node. No Exceptions. I restarted the dead node and reconnected it to the network. It re-joined the cluster, and the invocations were distributed among the two nodes again. That's why I am fairly certain that things go wrong during undeployment. Perhaps now the situation is clearer and someone can give me a hint on this? Thanks a lot. :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927111#3927111 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927111 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Ha, I figured it out (talking to myself seems to help a great deal ;) No
offense I know you are most likely on the other side of the planet and are
probably still asleep while I am writing this)
Anyway... I had a look at the ProxyFactoryHA , and came across this:
| 151protected void containerIsAboutToStop ()
| 152{
| 153 if( target != null )
| 154 {
| 155 target.setInvocationsAuthorization
(HATarget.DISABLE_INVOCATIONS);
| 156 target.disable ();
| 157 }
| 158}
|
After some more asking google for sourcecode I found out that target.disable()
does a
this.partition.getDistributedReplicantManager().remove (this.replicantName);
|
which - it seems to me - removes all replicas (removes it's localReplicant
and propagates the remove operation to all other nodes on the cluster) ...
I take it this is not a bug, but rather the expected behavior for this class ?
As I said I am pretty new to this and could not find much documentation...
anyway.. I discovered eralier that the stop() and destroy() methods of the
ProxyFactoryHA seem to be sufficient to disable the replicant anyway.. so I
simply made a new subclass which does nothing in the containerIsAboutToStop()
method:
| public class CustomProxyFactoryHA extends ProxyFactoryHA {
|
| protected void containerIsAboutToStop() {
| //do nothing
| }
|
| }
|
and updated my jboss-service.xml file:
| mbean code=at.arsenal.spirit.commons.jndimbean.CustomProxyFactoryHA
name=jboss.test:service=ProxyFactory,name=HAService,protocol=jrmpha
|
|
now everything seems to work absolutely smoothly. Turn off node, switch
node back on... everything behaves as I would expect it to.
Looks like this solved my problem. Or am I missing something else which I could
have broken with this patch? :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3927141#3927141
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927141
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Sorry if I am annoying.. one more thing I stumbled upon.. Clustering the MBean and deploying it via the JBoss farming service works very well now.. I tried the RoundRobin and RandomRobin LoadBalancing Policies and this works the way one would expect (impressively easy once you get it going, I love it :-) ).. the next thing I tried was fooling around with the failover behavior of the clustered MBeans and I noticed some strange behavior (I am not blaming JBoss but rather my cluelessness, but I really dont know what I am doing wrong here)... I have a cluster of three nodes. Two of them (Node A and Node B) run the clustered MBean service I have been developing. They are deployed via the farming service, and each of them creates a ProxyFactoryHA. The third node (Node C) looks up the ProxyFactory via HA-JNDI and performs a number of invocations on the MBean. These invocations are evenly distributed between the two MBeans as one would expect.. Now my problem is the failover: as soon as one of the MBean nodes (say Node A) fails (by shutting down the server via ctrl+c or the shutdown script) I would expect the Node B to receive all the invocations from Node C. But instead, an exception is thrown on Node C: | java.lang.reflect.UndeclaredThrowableException | at $Proxy62.test(Unknown Source) | at at.arsenal.spirit.request.RequestListenerServlet.service(RequestListenerServlet.java:83) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) | at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159) | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) | at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) | at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) | at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) | at java.lang.Thread.run(Thread.java:595) | | | Caused by: org.jboss.invocation.ServiceUnavailableException: Service unavailable. | at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA.invoke(JRMPInvokerProxyHA.java:292) | at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227) | at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167) | at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:59) | at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) | ... 22 more | Still the cluster detects the failed node correctly and updates it's state, therefore I think the problem has somehow to do with the ProxyFactoryHA.. I fooled around a little and discovered, if I shut down the ProxyFactoryHA MBean of a Node by hand (call the stop() method of the MBean via the JMX Console) then all works as expected. The other Node gets all the Invocations, no exceptions. If I start the ProxyFactoryHA again (via JMX console) the Invocations are distributed again. But as soon as I shut down the Node via ctrl+c the invocations fail. When I restart the shut down node, the invocations succeed again, but now all calls are answered by the node that was restarted. The node that was running all the time is ignored now. Now this is just a guess, but I believe part of the problem is, that the JBoss server should call the stop() method of the ProxyHAFactory when it is shut down normally... but this would not solve the problem of a node failing (the failing Node would not call the stop() method of the ProxyFactoryHA, because it failed).. so my guess is that something with my configuration (posted a few messages above) is wrong.. or maybe the
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Thanks for your reply. In the meantime I have tried to implement a clustered MBean with Round Robin scheduling (I found the a message where the poster claims he has done this at http://www.jboss.org/index.html?module=bbop=viewtopicp=3834455#3834455). I have created an MBean (WorkflowControllerService) which extends the HAServiceMBeanSupport class, and exposes a test() method. The jboss-service.xml of the MBean looks as follows | ?xml version=1.0 encoding=UTF-8? | | server | |!-- Create JRMPHA proxy for our service -- |mbean code=org.jboss.proxy.generic.ProxyFactoryHA name=jboss.test:service=ProxyFactory,name=HAService,protocol=jrmpha | | !-- Use the default partition -- | depends optional-attribute-name=PartitionObjectNamejboss:service=DefaultPartition/depends | | !-- Use the standard JRMPInvoker from conf/jboss-service.xml -- | depends optional-attribute-name=InvokerNamejboss:service=invoker,type=jrmpha/depends | | !-- The load balancing policy -- | attribute name=LoadBalancePolicyorg.jboss.ha.framework.interfaces.RoundRobin/attribute | | !-- The target MBean -- | depends optional-attribute-name=TargetNamearsenal.at:service=WorkflowController/depends | | !-- Where to bind the proxy -- | attribute name=JndiNameMUH/attribute | | !-- The interface exposed to the client -- | attribute name=ExportedInterfaceat.arsenal.spirit.services.workflow.WorkflowControllerServiceMBean/attribute | | !-- Client side behaviour -- | attribute name=ClientInterceptors | interceptors | interceptororg.jboss.proxy.ClientMethodInterceptor/interceptor | interceptororg.jboss.invocation.InvokerInterceptor/interceptor | /interceptors | /attribute |/mbean | | | mbean code=at.arsenal.spirit.services.workflow.WorkflowControllerService name=arsenal.at:service=WorkflowController | | depends | jboss:service=HAJNDI | /depends | /mbean | /server | The service can be deployed just fine, and when I do a lookup I get a valid reference to a JRMPInvokerProxyHA class. But if I try to invoke the test() method on the Proxy I get an exception. Example code and exception follow: | WorkflowControllerServiceMBean controller = (WorkflowControllerServiceMBean)ctx.lookup(MUH); //lookup proxy | log.debug(Calling Test Method on Controller); | controller.test(); //exception here | The exception which is thrown is: | | 08:48:01,000 INFO [STDOUT] java.lang.IllegalArgumentException: null object name | 08:48:01,000 INFO [STDOUT] at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:494) | 08:48:01,001 INFO [STDOUT] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:638) | 08:48:01,002 INFO [STDOUT] at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java:163) | 08:48:01,002 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | 08:48:01,003 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | 08:48:01,003 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | 08:48:01,003 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:585) | 08:48:01,004 INFO [STDOUT] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) | 08:48:01,004 INFO [STDOUT] at sun.rmi.transport.Transport$1.run(Transport.java:153) | 08:48:01,005 INFO [STDOUT] at java.security.AccessController.doPrivileged(Native Method) | 08:48:01,005 INFO [STDOUT] at sun.rmi.transport.Transport.serviceCall(Transport.java:149) | 08:48:01,006 INFO [STDOUT] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) | 08:48:01,006 INFO [STDOUT] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) | 08:48:01,007 INFO [STDOUT] at java.lang.Thread.run(Thread.java:595) | 08:48:01,007 INFO [STDOUT] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) | 08:48:01,008 INFO [STDOUT] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) | 08:48:01,008 INFO [STDOUT] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) | 08:48:01,008 INFO [STDOUT] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) | 08:48:01,009 INFO [STDOUT] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA.invoke(JRMPInvokerProxyHA.java:172) | 08:48:01,009 INFO [STDOUT] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227) | 08:48:01,010 INFO [STDOUT] at
[JBoss-user] [Clustering/JBoss] - Re: MBean Clustering , JBoss 4.0.3
Ok nevermind, I found it out :-) If anybody is interested, the MBean needs to register itself at the Registry during startup. It also needs to expose an invoke() method, which injects the Method Resolution into the remote invocation... err sounds confusing, anyway the classes at http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/src/main/org/jboss/test/jmx/ha/ gave me an impression how it has to be done. Thanks for your time anyways :-) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3926520#3926520 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3926520 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - MBean Clustering , JBoss 4.0.3
Hi, I have searched the forums, but have found no recent information on this. This question has been asked before(in 2003): anonymous wrote : | I have a set of MBeans that provide services for my application. I would like to deploy these MBeans on multiple servers (for load-balancing and failover). I do not want to set them up as singletons, but I do want one and only one MBean to be utilized per request. I also would like to have the invocations of the MBeans load-balanced (any flavor is fine) and fault-tolerant (so that if a server goes down, the invocation of the service is routed to another server). | I am having the exact same problem and I am wondering if a nice builtin solution for this has been developed in the meantime. If someone could point me in the right direction (Articles, Example Code, anything) I would be most grateful. TIA. :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3925768#3925768 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925768 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
