Do you have an @org.jboss.ejb3.annotation.Clustered annotation on the bean
classes, or
true
in each bean's section in the ejb jar's jboss.xml?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203340#4203340
Reply to the post :
http://www.jboss.com/index.html
Make sure when you open a support ticket that you reference this thread so the
support team can see the background.
Please post the contents of your deploy/cluster-service.xml file.
Your farming issue for sure sounds like a communication issue; i.e. lost
messages, lots of retries. Not bad enoug
To change logging, edit the $JBOSS_HOME/server/.../conf/jboss-log4j.xml file.
But you should fix the underlying problem by doing what's described at "Two
Clusters Same Network". Current URL is
http://www.jboss.org/community/docs/DOC-12460
View the original post :
http://www.jboss.com/index.ht
This can be done by adding a bind_port attribute and a port_range attribute to
the UDP section of the various JGroups protocol stack configurations. By
default bind_port is "0" meaning the OS picks the port.
| http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203390#4203390
Reply to
"yairogen" wrote : No, I don't use this annotation. Trying to add it gave me
errors as I recall. This should be added on the bean class and not the
interface, right?
Correct.
anonymous wrote : I haven't tried adding the clustered true node in the
jboss.xml file. I don't have such a file.
| A
Your "ConnectionTable" logging:
| 09:02:22,093 WARN [ConnectionTable] peer closed connection, trying to
re-send msg
| 09:02:22,093 ERROR [ConnectionTable] 2nd attempt to send data failed too
is coming from the JBoss Messaging Data Channel. That channel uses TCP unicast
for sending message
"bmelloni" wrote : This Connection issue does not go away with the firewall
turned off. The two posts are independent problems.
|
| Let's table this problem. I should get my commercial license credentials
today or tomorrow and will use phone support to start over from scratch and
reinstal
Sorry, I don't have a good answer for you on this one; looks like a log4j
issue. If anyone else on this forum has any idea, please help out.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204050#4204050
Reply to the post :
http://www.jboss.com/index.html?mod
Yes, the annotation and the xml are equivalent; no need to use both.
Re: messaging-service.xml, don't change the file, but yes, in a cluster every
server needs a distinct value for the ServerPeerID property. The file uses
system property substitution syntax:
${jboss.messaging.ServerPeerID:0}
The web.xml I'm talking about is the one in your webapp war's WEB-INF. If the
webapp you're talking about is the default webapp that ships in
deploy/jboss-web.deployer/ROOT.war, then that's the right path. The
jboss-web.xml goes in the same dir as the web.xml.
View the original post :
http://w
Can you post the relevant section of your Spring config? Easier than asking 20
questions. :) The docs for the JndiObjectFactoryBean imply it will do the
lookup once and cache it.
My guess about what you are doing is you are creating a client and using
JndiObjectFactoryBean to handle the JNDI lo
"bstansbe...@jboss.com" wrote : Easier than asking 20 questions. :)
I meant easier than me asking 20 questions. :)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204841#4204841
Reply to the post :
http://www.jboss.com/index.html?module=
Strange. Can you post the stack trace of the NNFE?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204847#4204847
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204847
___
jbos
Let's assume you don't start JBoss with the -g switch, so your HAPartition is
named "DefaultPartition".
For AS 5:
| [...@besdev bin]$ ./twiddle.sh get
jboss:service=HAPartition,partition=DefaultPartition CurrentView
| CurrentView=[127.0.0.1:1099]
|
For AS 4:
| [...@besdev bin]$ ./t
Unless someone from the community gives you an answer here, I suggest you post
on the Portal forums and post a link to the thread back here. I'll follow the
thread and try to participate. But I don't know enough about the portal
internals to even know where to start.
View the original post :
h
"yairogen" wrote :
| Can you tell me something about a replacement?
|
| Maybe a JBoss spring bean? I heard there is something of the sort that is
Cluster aware.
|
Not that I know of, but there are lots of things out there.
Anyway, looking at your config and the JndiObjectFactoryBean
"rengar" wrote : One difference is that session always is
x.node1. Don't change name node.
Do you mean with AS 4.2.3 it's always .node1? Even after you shut
down node1?
If so, do you have "UseJK" set to "true" in your 4.2.3
deploy/jboss-web-deployer/META-INF/jboss-s
OK, I see what's going on here. The key difference between your two stack
traces is the thread involved. In the NNFE case, it's the JGroups thread that
carries messages up from the network. You then use the thread to instantiate an
SLSB, which then does an HA-JNDI lookup, which makes a group RPC
I'm still looking into this. Any information you can give me on how you are
using this bean in your test would be helpful. How many threads access the
bean, how do you track what node is handling the calls, etc. Ideal would be a
simple test app to show it. I've been experimenting and don't see
Do you have buddy replication enabled? (Not enabled by default.)
The bit about the session id always remaining xxx.node1 in 4.2.3 is
mysterious to me, as it shouldn't work that way. But I'll put that aside for
now since you've got the "UseJK" flag set.
View the original post :
http://www
OK, I'm going to need some sort of example application (even better a test
case) to show this problem. I've beefed up testing trying to demonstrate a
problem and I'm not seeing it.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205402#4205402
Reply to the po
"chtimi2" wrote :
| Here is what i do: i implement a TopologyChangeListener that uses the HA
MBean notification mechanism to send business commands (serializable command
pattern objects) to nodes on topology changes.
| And in my case i need to be sure the commands are executed in order, and
I just tried reproducing this with mod_jk and it worked fine. It will probably
be a couple days before I can try with mod_cluster. If you have mod_jk
available and can try with that, let me know.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205431#4205431
It should be invoked automatically when the application is deployed *on the
master node*, which typically would be the first node started in the cluster.
You should never have to call it from the JMX console.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205
Hmm, simple question, complicated answer from me.
First, I'll cut to the bottom line. Instead of deploying via a -service.xml,
use a -jboss-beans.xml:
|
|
|
|
|
|
|
@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="test:service=StartupTestingCFD2",
exposedInter
Great to hear; thanks yairogen for posting this for the benefit of others.
Trying to reproduce this led me to add some useful improvements to our test
suite, so good for JBoss software too.
Cheers,
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206113#420611
Please provide details of the AS version you are using and please confirm that
you've configured EJB3 to use the org.jboss.ejb3.entity.TreeCacheProviderHook.
Then are you calling flush() on your EntityManager as discussed on
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=148006 ?
I ha
I had a chance to poke around a bit. In the Hibernate code the only path I see
that results in the entire region for an entity being removed from the cache is
via the BulkOperationCleanupAction, which gets clears the cache region during
tx commit if the tx executed some "bulk operation". Typical
Yes, see comment I posted a half-hour or so ago on the other thread.
If you execute native queries, Hibernate has no way to know what changes you
are making in the underlying database, and is forced to aggressively clear the
cache to avoid leaving stale data.
Same thing applies if you do bulk u
There's really no way to answer that question; whether caching is beneficial is
highly dependent on the details of the application. I always encourage users to
load test and benchmark; try different combinations to see what works best.
You say "it's inadmissible for me to have clear cache so oft
Just a thought: the TransactionManagerLookup interface is meant to be a plug-in
point. You've been looking at the impls, so you can see that they aren't doing
anything particularly complex. So if need be you can write your own impl that
works in your environment.
View the original post :
http:
I googled "BAD packet signature 18245" and found a tomcat-users thread where
someone said this means someone sent an HTTP message to the AJP connector:
http://mail-archives.apache.org/mod_mbox/tomcat-users/200804.mbox/%3c48105bb4.6060...@apache.org%3e
View the original post :
http://www.jboss.c
What is going on in here?
| 10:12:57,502 ERROR [STDERR] at
javax.naming.InitialContext.lookup(InitialContext.java:351)
| 10:12:57,502 ERROR [STDERR] at
kdcs.timers.QuartzJob.jobInvoiceHandlerJob(QuartzJob.java:797)
| 10:12:57,502 ERROR [STDERR] at
kdcs.timers.QuartzJob.create
Your problem is the thread doesn't have the correct classloader assigned to it
via Thread.setContextClassLoader(). The clustered JMX notification is going to
be delivered by a thread coming up from JGroups:
17:29:36,315 INFO [STDOUT]
[com.navineo.sa.jmx.ha.taches.ComEmbarquesHAS][IncomingPack
You're correct that using JBC as a Hibernate Second Level Cache isn't what
you're looking for.
The HibernateCacheLoader class you linked was never part of JBoss Cache. It was
part of JBoss Portal. Looks like it was an implementation of a concept similar
to what you are talking about -- implemen
Perhaps the whole "wizard" thing is a red-herring due to a reverse DNS problem?
The word "wizard" appears here in the message of a
java.rmi.ConnectIOException; perhaps that's getting created with a call to
InetAddress.getHostName() which does a reverse lookup and says "wizard" when
it should
A couple techniques to get a ref to a classloader:
1) Call getClass().getClassLoader() on some class that you know was loaded from
the ear. From your stack trace
com.navineo.sa.jmx.ha.taches.DummyTacheEgoiste1HAS seems like a candidate.
2) You can call Thread.currentThread().getContextClassLoa
See "desired_avg_gossip" config attribute on
http://www.jboss.org/community/docs/DOC-10902.
For JGroups discussion of what may be the root cause of what you are seeing:
http://www.jboss.org/community/docs/DOC-11244
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic
There is something wrong with how JNDI is working in that application. That
stack trace shows that the call is using an HA-JNDI proxy to make a remote call
to an HA-JNDI server. That shouldn't be needed for code running inside the AS;
the org.jnp.interfaces.NamingContext.lookup() method should b
There's nothing simple, no. Nothing that aggregates data together from
different calls.
If you're using EJB2 and have log4j available on the client side, on the client
side you can enable TRACE logging of the org.jboss.invocation package; you'll
get info there on what node was chosen for each c
You'd need to provide more details on what you are seeing.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209652#4209652
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209652
I didn't change this; when I did the refactor that line was already as it is
now. I'm looking now at the history on the 5.x and 4.x branch to see if I can
figure out why it's commented.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209906#4209906
Reply to t
As far back as svn history goes on Branch_5_0 fka trunk (15/Mar/07, in the
TomcatDeployer class) this is commented out. In Branch_4_0 it was added on
4/25/05, r 30817 in the Tomcat5 class. That same commit included a change to
the equivalent class in trunk. I can't figure out how to see the cont
Not 100% sure but I think this got dropped when the old Branch_4_2 JBossWeb
class got merged into the TomcatDeployers class in trunk (later Remy and I
broke it back out.)
Bottom line though I don't see any reason jbrow shouldn't re-enable the
notification.
View the original post :
http://www
In the deploy/jboss-messaging.sar/clustered-hsqldb-persistence-service.xml
file's jboss.messaging:service=PostOffice mbean, try adding the following:
${jboss.partition.name:DefaultPartition}
I don't know why that isn't there by default; probably an oversight.
View the original post :
http://ww
Yes, in the jboss.messaging:service=PostOffice mbean.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210002#4210002
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210002
___
j
"nathanmesser" wrote :
| I have a transaction T1, which reads a node A from the cache, so it should
have a read lock on the node.
|
| This transaction is then suspended, when an EJB method is called with it's
transaction attribute set to requiresNew. This transaction T2 then writes to
th
Yes, the early format was deprecated in JBC 3, although it should still work
fine.
The schema shown on p 105 of the 3.0.2.GA userguide is for a single config,
while the old "cache-configs" format was used when you wanted to specify
several named configs in a single document, which is what
org.
Sorry, no.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210524#4210524
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210524
___
jboss-user mailing list
jboss-user@lists.jbo
In your persistence.xml use
instead of
.
This isn't strictly necessary though. OptimisticTreeCacheProviderHook is a
trivial subclass of TreeCacheProviderHook. Both are able to detect the cache's
NodeLockingScheme config and work appropriately. The only additional behavior
in OptimisticTr
The cache is only aware of database changes made through your EntityManager (if
you are using JPA) or Hibernate (if not).
If you add a record manually and then try to read it through the EntityManager,
you'll get a database read and thereafter the entity will be cached.
What's more of a problem
Apache knows nothing about how you've organized the backend servers beyond what
you configure in workers.properties. In workers.properties when you set up a
load balancer worker you list the regular workers it should balance requests
across. You need to limit that list to the workers that you wa
The load balancer (Apache) is what handles failover. The request comes into
apache and it decides how to handle it. If it sees the request's session is
associated with a backend server that is no longer available, Apache picks a
different server (i.e. fails over). If it passes the request throu
Looking at the javadoc for the 4.0.2 version of SingleScheduleProvider I don't
see a way to pass in the kind of arguments you want:
|/**
| * Sets the method name to be called on the Schedulable MBean. It can
optionally be
| * followed by an opening bracket, list of attributes
It's still in progress. Go to the bottom of
https://www.jboss.org/community/docs/DOC-12928 and there is a draft there.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211654#4211654
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
Answered in your other post at
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211379#4211379
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211996#4211996
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=421199
To answer your questions as numbered:
1)
a) You don't need to create your cache in jboss-cache-manager-jboss-beans.xml
unless it needs to be available to the standard clustering services JBoss AS
ships. You could include the config declaration in the
SPECjAppServer-jboss-beans.xml file along
Threads waiting on an object are quite normal; it's the standard mechanism via
which a thread that's completed it's work is unscheduled while waiting for more
work. The threads in your stack trace other than "main" all look fine. The
"main" thread wait is as I described above.
As nodes start, e
Mohit,
It turns out your employer has a support contract with Red Hat. Please use the
support case opened on our Customer Service Portal to resolve the issues you
are seeing. The CSP is a much better tool for handling complex operational
issues like what we're discussing on this thread.
Thank
I've asked the JGroups developers to respond to this question. VIEW_SYNC is not
one of the standard protocols we include in the JBoss AS channel
configurations, so I'm not as familiar with all of its pros and cons as I am
with most protocols, and I don't want to give you wrong information.
View
OK, but make sure you trace down that "FD drops the member it never detects
that member again" issue on the support case, as you shouldn't be experiencing
that behavior.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192312#4192312
Reply to the post :
http:
Not quite correct. FD doesn't "detect" a member, it validates that a known
member is still alive. After "max_tries" heartbeat messages without a response,
it initiates the process that leads to GMS excluding the non-responding member
from the group. The fact you have shun="true" in both FD and G
Thanks for the bug report. I think this is an issue that's been around for a
long time; it has to do with the way the HA proxy factories work with the
invokers. I'm looking now to see if there is a straightforward fix.
In the meantime, I'm going to post below the code from a test service that we
First, the service implementation:
| package org.jboss.test.cluster.invokerha;
|
| import java.lang.reflect.Method;
| import java.lang.reflect.InvocationTargetException;
| import java.lang.reflect.UndeclaredThrowableException;
| import java.security.Principal;
| import java.util.Co
Now the service's remote interface (not really relevant, just FYI) and its
mbean interface:
| package org.jboss.test.cluster.invokerha;
|
| import java.io.IOException;
|
| public interface HAServiceRemote
| {
|String hello() throws IOException;
|
|String getCluste
Finally, the deployment descriptor:
|
|
|
|
|
|
|
|
| jboss:service=DefaultPartition
|
|
| jboss:service=invoker,type=jrmpha
|
|
| org.jboss.ha.framework.interfaces.RoundRobin
|
|
| jboss.test:
Now I bit more about the problem.
The detached invokers , e.g. JRMPInvoker or JRMPInvokerHA work by unmarshalling
an Invocation object off the wire, getting the ObjectName of the target service
from the invocation, and then making a call on the MBeanServer similar to this:
| Object returnVal
You need to use a separate InitialContext with a distinct set of naming
environment properties for each cluster. Even if autodiscovery could be
configured to discover both clusters, the downloaded naming proxy would come
from one or the other and would only be able to connect to servers in that
"cdelory" wrote :
| In the mean time, I figured out another workaround: use the "regular" JRMP
proxy factory, which registers a local JNDI name on each target server, and go
through HA-JNDI to perform the cluster lookup of one of my registered services.
The bad side here is that I cannot real
I'm not sure from your description exactly what it is you are doing, but I
suspect your client threads are running in the JBoss server VM. In that case,
JBoss will detect that the client is in the same VM and will route invocations
to the local bean as a performance optimization.
When we load/
To look up two different EJB applications deployed on two different clusters,
the client will need to create more than one InitialContext.
The contents of jndi.properties will be combined with whatever other properties
you
pass in via a call to new InitialContext(Hashtable environment). So I
w
Correct; entities are not shared on the cluster through a common cache. There
is a cache invalidation framework (CIF), through which messages can be sent
around the cluster to invalidate the local caches on each node.
Some of the older versions of the clustering docs actually have better covera
Yes, the requests were balanced.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196274#4196274
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196274
___
jboss-user mailing lis
You can implement the org.jgroups.ChannelListener interface
(http://www.jgroups.org/javagroupsnew/docs/javadoc/org/jgroups/ChannelListener.html
). You register your impl with the org.jgroups.Channel used by the cache via
the Channel.add/removeChannelListener(ChannelListener listener) methods. Y
If you continue to have problems, please post as many details as you can about
your test (e.g. what exactly each "user" thread does, info on how the EJBs are
configured/deployed).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196676#4196676
Reply to the pos
I recently created a wiki page devoted to getting input on what people would
like to see done in JBoss AS Clustering, and in the AS in general, over the
next 6 to 18 months. I'd very much welcome your input; please see:
http://www.jboss.org/community/docs/DOC-13209
It's a wiki with comments, s
I just pinged the JGroups folks again. You can also try the jgroups user mail
list at https://lists.sourceforge.net/lists/listinfo/javagroups-users .
Re: HASingletonController, first thing to understand is that who the master is
is a function of what nodes in the cluster have that HASingletonCon
My guess is your session replication channel is *not* using TCP.
GMS: address is 172.16.64.21:32804
32804 seems more like a port the UDP configs would use.
The session replication channel isn't configured via cluster-service.xml. It's
via tc5-cluster-service.xml or
jboss-web-cluster.sar/META-I
I don't have any specific log categories, no, as without more information on
what's increasing in the heap there's not much to go on.
When n1 is shut down, n2 starts getting failover requests and starts doing
twice as much work, so memory increase is expected. Perhaps the increase would
be a bi
http://anonsvn.jboss.org/repos/jbossas/tags/JBPAPP_4_2_0_GA_CP06/tomcat/src/main/org/jboss/web/tomcat/service/session/
is the package where the distributed session manager code resides.
http://anonsvn.jboss.org/repos/jbossas/tags/JBPAPP_4_2_0_GA_CP06/tomcat/src/main/org/jboss/web/tomcat/service/s
I've commented on the JIRA, but will go into a bit more detail here.
First, the logs you sent me, Adam, showed the file that was being farmed was
actually "xxx.ear.filepart" not "xxx.ear". From that I believe you were using a
tool (perhaps WinSCP?) to upload the file directly to the farm directo
That should be doable. What I described before was focused on the JMS server.
And with it you have a server running on every node. The queue is independent;
it can be deployed via deploy-hasingleton and that will work as long as there
is a JMS server running on its node. Which there will be.
Hm
Please cut and paste the full protocol stack configuration. What you posted
looks OK, so I want to see an unedited version.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258690#4258690
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=postin
Your logging is coming from the JBoss Messaging channels, which do not use the
"udp" protocol stack. They use "jbm-control" and "jbm-data" lower down in the
same file. So you'll need to add AUTH there as well.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=425
Thanks, Richard, for this thorough report. How are you restarting server B?
Hard kill + restart, or normal shutdown plus restart? If it's a hard kill, have
you edited the AS's JGroups configurations to remove FD_SOCK?
I doubt you have removed FD_SOCK; the above questions are just to remove one
Yes, my line of thinking on FD_SOCK was as you stated. Very much a long shot.
:-)
Thanks for testing with 3 nodes. This afternoon I'm setting up a basic unit
test with two nodes; will report back here.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259947#42
Good question. Complicated answer.
First, if you want to try to get this to work, you can disable buddy
replication in your JBC config and also update the JBC config's
cacheLoaderConfig section:
false
That's "true" by default.
The issue with reading sessions off the disk at startup is that th
Richard, this is most definitely a bug.
https://jira.jboss.org/jira/browse/JBCACHE-1549
Thanks again for the thorough report.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259964#4259964
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=post
Thanks for confirming that. What you're trying to do is valid; it's just that
it requires real caution when used in an actual cluster with production data,
so it's not the default.
That technique won't work if the JBC config has "useRegionBasedMarshalling" set
to true. Which in AS 5.1 is only t
Are you saying you made serialVersionUID a mutable field and are setting it to
one on some instances of the class? That won't work; the java io classes (not
JBoss) compare the value read from the stream to the value of the Class object.
View the original post :
http://www.jboss.org/index.html?
I suspect you have different versions of the class on the classpath.
Caused by: java.io.InvalidClassException: com.company.generated.MyNode; local
class incompatible:
| stream classdesc serialVersionUID = 1, local class serialVersionUID =
-7258818124315218931
JBoss is not generating that loca
Something got messed up in your paste of cluster-service.xml.
Also, I thought you'd said on IRC that you were using a TCP protocol stack?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260837#4260837
Reply to the post :
http://www.jboss.org/index.html?module
I don't recommend UDP.send_on_all_interfaces=true.
UDP.receive_on_all_interfaces=true is a bit suspect too, although not as much
as send_on_all_interfaces. It's much better IMO to pick a common network and
bind all nodes to an interface on that network it using -b xxx or
-Djgroups.bind_addr=xxx
Re: 2.6.13 and AS 4.2.3, I personally haven't tried any 2.6 series release with
AS 4.x. So I'll defer to the rest of the community for detailed input.
The 2.6 series is API compatible with the 2.4 series used in AS 4.2.x, and the
fundamental semantics of Channel behavior are the same, so it shou
"axelerator" wrote : Hi Brian,
|
| thanks. That's a good lookout. Also I tested the setup and AS started
without any itches and behaved pretty much normally.
| What I'm nevertheless a bit curious about is the use of synchronous RPC
calls (callMethodOnCoordinator) with regards to performan
JGroups is only going to allow one message at a time from a particular sender
to proceed up the stack past UNICAST. This is needed to ensure message are
delivered in order. So, only one RPC at a time.
There's a JGroups JIRA to add an API whereby the application can define the
scope to which mes
What AS release is this?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261371#4261371
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261371
___
jboss-user mailing list
jboss-
That exception is thrown when the ClusterChooserInterceptor cannot find any
more targets to try; the "Caused by: org.jboss.remoting.CannotConnectException"
is telling you what the exception was from the last target it attempted. So the
question is why there are no other targets to try if you've
What did your Service bean implementation look like?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261374#4261374
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261374
___
jb
How are you deploying this LayoutMBean? You opened another thread asking
whether an HAServiceMBeanSupport subclass could be deployed via a war. I
suppose it could, but your code in your war (presumably a
ServletContextListener) would have to do all the normal stuff JBoss AS does
when it deploys
201 - 300 of 329 matches
Mail list logo
