JBoss Cluster Questions -- Apache + Mod_jk + JBoss Nodes
by xu Feng
Hi Everyone,
Now I want to build jboss cluster which can deploy web applications.
I decide to use such architecture:
Jboss Node1
apache + mod_jk +
Jboss Node2
I have two questions:
<1>can i both set session_sticky on mod_jk and session_replication on Jboss
Node1 and Jboss Node2? Can the two settings conflict with each other?When
one Jboss died while one clients visits , how mod_jk behave if I set the two
in the configuration files?
<2>Is it a classic or typical implementation for JBoss Clustering as is
suggested on JBoss Guide?
<3> can I both achieve High Availability and Load Balance all in one such as
above?
Thank you in advance.
Xu Feng
Yuanjie Networks,Shanghai,China
MSN: xufengnju(a)163.com
18 years, 1 month
[JNDI/Naming/Network] - Re: non-JRMP server at remote endpoint
by kahzoo
anonymous wrote : javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: non-JRMP server at remote endpoint]
| at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:97)
| at javax.naming.InitialContext.lookup(InitialContext.java:355)
| at org.objectweb.carol.jndi.spi.AbsContext.lookup(AbsContext.java:134)
| at org.objectweb.carol.jndi.spi.AbsContext.lookup(AbsContext.java:144)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| at org.objectweb.carol.jndi.spi.MultiContext.lookup(MultiContext.java:118)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
|
You might want to check the contents of your jndi.properties file (or the code portion that does 'new InitialContext(hashtable)' if you're setting the jndi properties programatically).
If you are trying to connect to JBossNS, the contents of the jndi.properties typically looks like the following (the host portion varies depending on your environments).
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
| java.naming.provider.url=jnp://localhost:1099
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136158#4136158
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136158
18 years, 1 month
[JBoss Tools (users)] - Re: upgrade to WTP 2.0.2 breaks EAR deployment in JBoss Tool
by rob.stryker＠jboss.com
Ok... so here's what I've discovered so far. Methodology is similar to yours. Open an eclipse with wtp-2.0.1 workspace and create a seam project (seam 2), make sure it deploys appropriately (it does), close down eclipse.
Open a new eclipse with wtp-2.0.2 but use the same workspace.
The very first thing I notice is a stacktrace in the output (starting from command-line). Trace is as follows:
[rob@localhost eclipse]$ ./eclipse
Listening for transport dt_socket at address: 4000
*** ERROR ***: Wed Mar 12 19:27:50 EDT 2008 org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0006E Archive is not a valid Application Client JAR File because the deployment descriptor can not be found (case sensitive): META-INF/application-client.xml
at org.eclipse.jst.j2ee.internal.componentcore.EnterpriseBinaryComponentHelper$ArchiveCache.openArchive(EnterpriseBinaryComponentHelper.java:339)
at org.eclipse.jst.j2ee.internal.componentcore.EnterpriseBinaryComponentHelper.openArchive(EnterpriseBinaryComponentHelper.java:149)
at org.eclipse.jst.j2ee.internal.componentcore.EnterpriseBinaryComponentHelper.getUniqueArchive(EnterpriseBinaryComponentHelper.java:79)
at org.eclipse.jst.j2ee.internal.componentcore.AppClientBinaryComponentH
elper.getPrimaryRootObject(AppClientBinaryComponentHelper.java:110)
at org.eclipse.wst.common.componentcore.ArtifactEdit.getContentModelRoot
(ArtifactEdit.java:540)
at org.eclipse.jst.jee.internal.deployables.JEEDeployableFactory.createB
inaryModules(JEEDeployableFactory.java:163)
Tracing through, this happens during startup for me because I made sure to have the JBossServers view up which probably helped force the initialization of the deployable factories. blah blah ;) Moving along.
I stopped the trace at createBinaryModules because this, I feel, is the important part. This is where the model for this project is started. Looking at the code for this method, we see the following. (context: It's parsing through the list of objects in the application.xml's module tags). Here are some snippets.
| if (moduleComponent.isBinary()) {
| // create an ear edit, app only if the module is binary prevents exceptions when there
| // is no deployment descriptor in many cases see bug 174711
| if(earEdit == null){
| earEdit = EARArtifactEdit.getEARArtifactEditForRead(component.getProject());
| app = earEdit.getApplication();
| }
| // if we are missing the application.xml, cannot check for module URI so assume an archive
| if (app == null) {
| continue;
| }
|
So it's obvious they're trying to make sure if it's binary and has no application.xml, to just give up on it and accept that it's a generic archive.
The problem is despite their best efforts, this is not working. It is returning something. app is not null. The code fails at the following place.
| else if (j2eeModule.isJavaModule()) {
| moduleEdit = ComponentUtilities.getArtifactEditForRead(moduleComponent,
| J2EEProjectUtilities.APPLICATION_CLIENT);
| ApplicationClient appClient = (ApplicationClient) moduleEdit.getContentModelRoot();
| moduleType = J2EEProjectUtilities.APPLICATION_CLIENT;
| moduleVersion = appClient.getVersion();
| }
|
So basically, the top snippet tries to screen out generic java modules, but somehow fails. When it gets to the second snippet, it's assuming it's an application client jar, not a generic archive.
This is most definitely an upstream wtp bug and I will mark it as such and push it to tim and the server team. I'll also continue looking into it and try to provide a patch to eclipse.
- Rob
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136153#4136153
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136153
18 years, 1 month
[JBoss Tools (users)] - Re: XHTML files and content assist with custom tags
by Kragoth
Well, I've made progress. By creating the XSD file I can get attribute auto completion. But, I do not get tag auto complete. In that I have to know the name of my tag, but once i have put in my tag eg <gekko:inputTextbox /> it will then give content assist for my attributes.
I'm not entirely sure why it works for attributes but not tags. Seems rather odd.
The other problem I have is that most libraries eg jsf and facelets use tld's but I seem to be only able to get content assist to work with xsd files. So when I extend a jsf component I have to copy all the tld information into an xsd file which is just long and tedious.
Basically Jboss tools needs to allow the inclusion of a tld file that is not inside a jar.
Or maybe a step by step tutorial on how to get content assist working for custom tags would be nice. Especially the cases where I am extending an existing tag.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136143#4136143
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136143
18 years, 1 month
[JBossCache] - Random 1.6gb object allocation attempt when using tcpping
by youngm
We are using jbossCache 1.4.1.SP8 jgroups 2.4.1.SP4 on websphere 6.1 (IBM JDK AIX)
This is our config string:
| <config>
| <TCP start_port="58000" sock_conn_timeout="500" send_buf_size="150000" recv_buf_size="80000" loopback="false"
| use_send_queues="false" />
| <TCPPING timeout="2000" down_thread="false" up_thread="false" initial_hosts="host1[58000],host2[58000]"
| port_range="100" num_initial_members="1" />
| <MERGE2 min_interval="10000" max_interval="20000" />
| <FD_SOCK />
| <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" />
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192" up_thread="false"
| down_thread="false" />
| <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" />
| <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" />
| <FRAG frag_size="8192" down_thread="false" up_thread="false" />
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" />
| <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
| </config>
|
Our current configuration contains only 2 nodes.
We are seeing a problem where after about a week of normal operation we see some random 1.6gb byte[] allocation attempts. One of our apps attempted to allocate 33 of these 1.6gb byte[]s and it hung the app. We took a thread and GC dump from our of our frozen applications and noticed the following.
1. We had 33 jgroups send threads hung. 32 of these thread dumps had the following stacktrace:
| 3XMTHREADINFO "ConnectionTable.Connection.Sender [10.98.111.61:58001 - 10.98.111.61:58001]" (TID:0x36E07400, sys_thread_t:0x37379850, state:CW, native ID:0x001D20B5) prio=5
| 4XESTACKTRACE at java/lang/Object.wait(Native Method)
| 4XESTACKTRACE at java/lang/Object.wait(Object.java:199(Compiled Code))
| 4XESTACKTRACE at org/jgroups/util/Queue.remove(Queue.java:257(Compiled Code))
| 4XESTACKTRACE at org/jgroups/blocks/BasicConnectionTable$Connection$Sender.run(BasicConnectionTable.java:686(Compiled Code))
| 4XESTACKTRACE at java/lang/Thread.run(Thread.java:810(Compiled Code))
|
The other thread was:
| 3XMTHREADINFO "ConnectionTable.Connection.Receiver [10.98.111.61:58000 - 10.98.111.62:52906]" (TID:0x36CEAA00, sys_thread_t:0x36D12D08, state:R, native ID:0x00125049) prio=5
| 4XESTACKTRACE at java/net/SocketInputStream.socketRead0(Native Method)
| 4XESTACKTRACE at java/net/SocketInputStream.read(SocketInputStream.java:155(Compiled Code))
| 4XESTACKTRACE at java/io/BufferedInputStream.fill(BufferedInputStream.java:229(Compiled Code))
| 4XESTACKTRACE at java/io/BufferedInputStream.read1(BufferedInputStream.java:267(Compiled Code))
| 4XESTACKTRACE at java/io/BufferedInputStream.read(BufferedInputStream.java:324(Compiled Code))
| 4XESTACKTRACE at java/io/DataInputStream.readFully(DataInputStream.java:202(Compiled Code))
| 4XESTACKTRACE at java/io/DataInputStream.readInt(DataInputStream.java:380(Compiled Code))
| 4XESTACKTRACE at org/jgroups/blocks/BasicConnectionTable$Connection.run(BasicConnectionTable.java:575)
| 4XESTACKTRACE at java/lang/Thread.run(Thread.java:810)
|
The 32 threads are associated with sequential ports 58001-58033 so it appears jgroups is scanning the ports to determine if there are any new nodes in the cluster?
We have not been able to duplicate this problem when using "mping" instead of "tcpping" for member finding however we are not allowed to use multicast in our production environment.
We are going to try and change our port_range to smaller number to see if that helps. does anyone on the board has any other ideas?
Mike
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136139#4136139
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136139
18 years, 1 month
