[JBoss Messaging] - Re: ClusteredConnectionFactory vs JmsXA
by ejb3workshop
That depends how one looks at it. I completely accept your argument on using resources optimally. However the bean pool size might not be the best measure. If we deploy our application onto a cluster of nodes using single core CPU, a smaller bean pool is required to get optimal distribution, while if each node were a fancy quad core, a large bean pool would work just as well. I was hoping for an option to always distribute the work on a round robin basis. This would allow me to configure a standard bean pool, aiming to prevent overloading the system, rather then tuning the been pool size according to the hardware configuration of the cluster.
Maybe I misunderstand how load and idle periods are determined. Just from my observation it seems to be driven by the pool size.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158823#4158823
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158823
17 years, 10 months
[JBoss Messaging] - Re: Error when running clusters in two different machines.
by ebenezerlovelin
Hi,
I was able to start the two servers with out any problem. Now when I try to run the examples in the JBoss Messaging, it fails.
I was trying to run the distributed queue example.
I have two machine (192.168.200.151 & 192.168.200.124) and have two nodes (node0 & node1).
Node0 is in 192.168.200.151 and Node1 is in 192.168.200.124. I am running the client in node0 and I am trying to connect to the queue in the node 2 (In the jndi.property file, I gave java.naming.provider.url=jnp://192.168.200.124:1199)
I get this error run:
| [java] javax.naming.CommunicationException: Could not obtain connection to any of these urls: 192.168.200.124:1199 and discovery failed with error: javax.naming.CommunicationException: Failed to
| connect to server 127.0.0.1:1100 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 127.0.0.1:1100 [Root exception is java.net.ConnectException: Connection refuse
| d: connect]] [Root exception is javax.naming.CommunicationException: Failed to connect to server 192.168.200.124:1199 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to
| server 192.168.200.124:1199 [Root exception is java.net.ConnectException: Connection timed out: connect]]]
| [java] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1562)
| [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
| [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| [java] at javax.naming.InitialContext.lookup(InitialContext.java:351)
| [java] at org.jboss.example.jms.common.Util.doesDestinationExist(Util.java:55)
| [java] at org.jboss.example.jms.common.ExampleSupport.setup(ExampleSupport.java:214)
| [java] at org.jboss.example.jms.common.ExampleSupport.setup(ExampleSupport.java:194)
| [java] at org.jboss.example.jms.common.ExampleSupport.run(ExampleSupport.java:146)
| [java] at org.jboss.example.jms.distributedqueue.DistributedQueueExample.main(DistributedQueueExample.java:191)
| [java] Caused by: javax.naming.CommunicationException: Failed to connect to server 192.168.200.124:1199 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 19
| 2.168.200.124:1199 [Root exception is java.net.ConnectException: Connection timed out: connect]]
| [java] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:274)
| [java] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)
| [java] ... 8 more
| [java] Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 192.168.200.124:1199 [Root exception is java.net.ConnectException: Connection timed out: connect]
| [java] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:248)
| [java] ... 9 more
| [java] Caused by: java.net.ConnectException: Connection timed out: connect
| [java] at java.net.PlainSocketImpl.socketConnect(Native Method)
| [java] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
| [java] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
| [java] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
| [java] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
| [java] at java.net.Socket.connect(Socket.java:520)
| [java] at java.net.Socket.connect(Socket.java:470)
| [java] at java.net.Socket.<init>(Socket.java:367)
| [java] at java.net.Socket.<init>(Socket.java:267)
| [java] at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
| [java] at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
| [java] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:244)
| [java] ... 9 more
| [java]
| [java] #####################
| [java] ### FAILURE! ###
| [java] #####################
Am I missing something in the configuration?
Thanks,
Ebe
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158809#4158809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158809
17 years, 10 months
[JBoss Tools (users)] - Re: Incremental Archive deployment without WTP in 2.1.0.GA
by cpopetz
That's great to hear. I've just downloaded the latest nightly, and will give it a try.
Here's a question. I see two ways of approaching deploying sub-deployment archives with these tools. One would be to have the war project have a .war archive in "Project Archives," the ejb jars have their own archives, etc. The other way is to have my ear project package up everything from other projects, as I described in my original post.
I'm wondering which is preferred, or maybe, which is simply more tested and less likely to have bugs :)
The case of having each project handle its own archive makes sense in terms of clarity, but since each sub-deployment archive .package entry has to know the directory of the ear archive to publish _to_, there's still a dependence there. And I'm worried about splitting them all up for fear of triggering bugs. For example, if different sub-deployment projects are simultaneously incrementally publishing their contents during a build to jboss, will jboss survive, or will I get incomplete deployments?
On the other hand, in the "one project with archives to rule them all" approach, if changes are made to files in the war project, and the ear project has an archive that references those files, will incremental deployment of the ear/war happen even if the ear project has no project dependency (in the build path) on the war project?
Thanks for any advice. And thanks again for providing a way to avoid using WTP, which has singed my eyebrows too many times to believe "really, in this next release the tools are stable and usable."
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158805#4158805
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158805
17 years, 10 months