Yes, if you run on the VPN route, then kill the VPN session while you are still
connected.
You could set the interface (NIC) to use explicitly by setting
UDP(bind_addr="1.2.3.4") or -Dbind.address=1.2.3.4
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&
This means the routing table changed *while* you were running JBoss. Did you
pull a plug ? On Windows, 'media sense' will unplumb that interface.
You can set UDP(loopback="true";...) to work around the problem.
Bela
View the original post :
http://www.jboss.org/ind
So do you want me to add that 'ignore.bind.address' system prop now, or not ?
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854618#3854618
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=postin
Yes, this is on the roadmap, we'll do it for 1.2 if we finish this before end
of November, otherwise it will be the first task on the 1.3 roadmap.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854592#3854592
Reply to the post :
http://
.6, if you use -b or --host, then this *overrides* the
UDP.bind_addr property in the cluster-service.xml .
Let me know if this is a problem for you. An option might be to add another
system prop that ignore the -Dbind.address property.
Bela
View the original post :
http://www.jboss.org/index.h
Yes.
Multiple subnets: make sure IP multicasting is enabled and set the ip_ttl high enough
WANs: use a TCP-based configuration.
Check out the docs at jgroups.org for details on how to do that.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3852684
I just re-ran 3.2.6:
run.sh -b 127.0.0.1 -c all
and it *did* bind to the correct address.
In 3.2.6, if you use -b or --host, then this *overrides* the UDP.bind_addr property in
the cluster-service.xml
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtop
Post your cluster-service.xml
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3852401#3852401
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3852401
Have a look at total_token.xml in JGroups/conf (JGroups distro).
Note that I will start rewriting (or improve) TOTAL_TOKEN early next year.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850500#3850500
Reply to the post :
http://www.j
You need to switch NAKACK and STABLE, like below:
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850354#3850354
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3850354
-
Hmm, please enable logging (as described). I cannot find the "larger message" error in
any of the newer JGroups versions (starting from 2.2.4).
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849923#3849923
Reply to the post :
ht
Hmm, this is strange because the message size is *0* ! So this is probably caused by
another exception.
You could enable logging: add a category for org.jgroups.protocols.UDP at the TRACE
level.
What version of JGroups ?
java -jar server/all/lib/jgroups.jar org.jgroups.Version
Bela
View the
Post your cluster-service.xml. You probably need to defined a frag_size in FRAG.
Use JGroups/bin/frag_size.sh to determine the optimal fragmentation size.
Bela
P.S.: you'll also need to specify the frag size in NAKACK
View the original post :
http://www.jboss.org/index.html?module=
In initial_hosts, just list *all* hosts, or most of them.
Simply add the STATE_TRANSFER protocol from the UDP config, you'll need it for JBoss.
There's a tcp.xml in JGroups/conf (from the JGroups (src) distro)
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&am
http://www.jgroups.org/javagroupsnew/docs/newuser/node63.html
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848951#3848951
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3848951
---
, 6 weeks (possible dependecy on JBossMX)
* [Independent of JBossCache development]
- HAJNDI implementation
- Dev1, 6 weeks
[Independent of JBossCache development]
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848929#3848929
Reply to
This should *not* happen ! You should be able to access node2 immediately. Can you
take a stack trace on node2 when it hangs for the 60 secs ?
Also post your cluster-service.xml.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848281#3848281
If you run a *TCP* based configuration, you will *not* see this problem. At least not
in JChannel, but HAJNDI uses multicast as well.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847775#3847775
Reply to the post :
http://www.jboss.org/in
I just ran this with the latest CVS from the 3.2 branch (a.k.a JBoss 3.2.6RC3, and it
worked without problems. Are you sure you have a cluster, ie. could you check in
jmx-console --> DefaultPartition --> CurrentView attribute should show 2 instances.
Bela
View the original post :
post your cluster-service.xml
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847704#3847704
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3847704
---
This SF.Net ema
If you use the default config, and replace FD with FD_SOCK, then traffic will be
*null* when there is no data between the nodes (e.g. replication messages).
Isn't it the case that you're seeing lots of trafic because you are making a lot of
changes, thus replicating a lot ?
Bela
Sorry, incorrect information: you set the invalidation mode in the InvalidationManager
MBean; it is called "AsynchronousInvalidation". By default it is *asynchronous* not
synchronous.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846
1. If you want to use the InvalidationManager directly, all invalidateXXX() calls have
a 'async' boolean parameter.
2. If you use the EntityBeanCacheBatchInvalidatorInterceptor, then all invalidations
are synchronous by default (a.k.a hard-coded).
Bela
View the original po
Yes, you can make this asynchronous, depending on what you use. E.g. in HTTP session
clustering you can switch from "instant" replication to "interval" replication.
For the TCP-based config, check out jgroups.org -> User's Guide for an example
Bela
Vi
No, there's no system property for mcast_addr. The problem is that a JBoss node can be
member of multiple clusters, then you wouldn't be able to use a single system prop.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845795#3845795
Pulling the plug should result in a viewAccepted() callback. Depending on the
parameters of FD it will take more or less time.
I have done this before on various systems, and it has always worked.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p
The dead member should be removed from the membership, but only if you use FD rather
than FD_SOCK in (cluster-service.xml)
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845573#3845573
Reply to the post :
http://www.jboss.org/index.html?modu
use bind_addr in in cluster-service.xml
(search this forum for bind_addr)
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845216#3845216
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
afaik. The HASingleton simply relies on callbacks received by the underlying JGroups.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845188#3845188
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
This is part of JGroups, MERGE2 protocol plus GMS.
You could write your own JGroups protocol to replace the existing algorithm.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845138#3845138
Reply to the post :
http://www.jboss.org/index.htm
BTW: the --host switch suffices here, no need for bind_addr in the parameters for
JGroups.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3844937#3844937
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
I fixed this in the CVS. Did it for UDP, but apparently forgot TCP...
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3844936#3844936
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
JGroups dev list
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3842487#3842487
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3842487
---
This SF.Net email is sponsor
Change the bind_addr from "localhost" to a real IP address.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3842323#3842323
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=postin
ion
- filename
- URL
- filename on classpath
So I have to have some logic to handle these in the same method anyway. Also, I don't
want to have 5 constructors for JChannel. 2-3 maybe, but you have to convince me first
:-)
Bela
View the original post :
http://www.jboss.org/index.html
oups 2.2.5+) throws an exception when it sees the 2.2.4
version.
- Look into jboss-3.2/thirdparty/javagroups/lib/README. The tag used to create JGroups
is in there (possibly JG_2_2_4).
- Check out JGroups (co -r JG_2_2_4 JGroups)
Bela
View the original post :
http://www.jboss.org/index.html?mo
Done (in CVS). If you happen to have some spare time, you could merge the 2 parse
methods into 1, I think we could easily extract a common method used by the 2 parse()
methods...
Bela
"jiwils" wrote : Your XMLConfigurator changes added a bug, and it makes your changes
unlike
My bad - XmlConfigurator.parse(Element) was still using the old format. I changed it,
essentially copied XmlConfigurator.parse(InputStream).
Try it out now, need to get JGroups from the CVS.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3841968
Randomly selecting mcast ports doesn't work, because the mcast ports have to be the
same across a cluster !
This technique works for unicast sockets, however, and there is an example in UDP.java.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&
No benefits. Just change the mcast_addr/port, so you don't have to change the
partition name everywhere.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840551#3840551
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=p
No, I consider this an error: same IP mcast address, same port, but different
partition name.
I suggest changing the port and/or address instead of - or in addition to - the
partition name
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840504
You could also replace FD with FD_SOCK, so you establish sockets between peers rather
than use messaging/heartbeating to detect a crashed server.
Note, however, that this will *not* exclude a hung server.
Also search for my more detailed expl on this forum earlier.
Bela
View the original post
bind_addr=127.0.0.1 will bind to the loopback, even if both nodes are on the same
machine this may be flakey. Try without the bind_addr, or set it to a well-known
interface.
You could also try with the latest JGroups, which I want to put out this weekend.
Bela
View the original post :
http
om cluster-service.xml into a file, e.g. test.xml, and start
Draw like this:
java -Dlog4j.configuration=file:c:\log4j.properties org.jgroups.demos.Draw -props
c:\\test.xml
c:\log4j.properties needs to have an entry for org.jgroups set to DEBUG.
Bela
View the original post :
http://www.jboss.org/
To make JGroups bind to a specific NIC, use the bind_addr parameter to the JGroups
configuration in cluster-service.xml for now.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838164#3838164
Reply to the post :
http://www.jboss.org/index.html?m
on't know what you are talking about ...
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838163#3838163
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3838163
m property resolve.dns, which disables DNS resolving. By default it is
"true" (resolving enabled).
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838007#3838007
Reply to the post :
http://www.jboss.org/index.html?module=bb&
m property resolve.dns, which disables DNS resolving. By default it is
"true" (resolving enabled).
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838006#3838006
Reply to the post :
http://www.jboss.org/index.html?module=bb&
"hbaxmann" wrote : Hi Bela,
|
| thanks a lot, I was hoping to demonstrate this kind of functionality to a
customer, than he has to wait till the next (3.2.5 ??) release :-(
|
| Any timeframe for this?
|
| wbr
| bax
|
|
You can use -DUDP.bind_addr for now, e.g. pr
.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837988#3837988
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3837988
---
This SF.Net e
Here's a quick build of jbossha.jar: www.jgroups.org/jbossha.jar. No guarantees it
will work with your version of JBoss, you're on your own.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837879#3837879
Reply to the post :
ht
You don't need a jgroups.jar, but a jbossha.jar
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837878#3837878
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&
Yes - this will be JBossCache configured with a CacheLoader. Stay tuned for JavaOne.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837804#3837804
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
"tbauer" wrote : Thanks Bela and Scott...I appreciate you prompt reply...
| I will keep an eye out for an updated version on sourceforge (I'm not savy enough
to build everything myself).
|
| cheers,
|
| tim
|
It is actually quite simple, but we'll put out a pat
y* of BatchInvalidations, rather than a single object.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837654#3837654
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&
ClusterPartitionMBean.getCurrentView().size()
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3836170#3836170
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
this works, but you have to have the same versions of the JDKs.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3835395#3835395
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
set the category "org.jboss.ejb.plugins to WARN (or INFO should work too in that case)
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3835305#3835305
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&
"tbauer" wrote : Okay, seems to work now...but one question?? I have ALWAYS gotten
| this message on the console...
| How (or what) is a valid multicaset address/port given I want to
| hardcode the IP address in the HANamingService section of the .xml
|
|
| 18:35:14,978 INFO [HANam
he tracing level for org.jgroups.protocols.{TCP,TCPPING} to WARN
because they still use INFO, which is too verbose. I just checked in the changes which
now uses TRACE as logging level.
So setting the 2 cats is a temp solution, until the new version of JGroups is shipped
with JBoss (3.2.4RC3).
"tbauer" wrote : okay, so I have tcp.xml, but how and where do I put this file (or
it's contents) in JB 3.2.4FC2 to make it work??
server//deploy/cluster-service.xml. Just replace the matching tag with the contents
of tcp.xml, e.g.
XSAM_Partition_XSAM26B_partition
s was caused by the conversion from trace to commons-logging. I
already changed this in the JGroups CVS, but for now excluding these cats is the only
way to solve this.
I'll be at JavaOne, come to my BOF and you can bang my head with a baseball bat to let
off some steam ... :-)
Bela
View th
No, this works. I use the BindingService on node-2, and it works perfectly.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3835217#3835217
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
I plan to add a flow-control based configuration to JBoss soon. However, this requires
some stuff in JGroups that's fairly new. This will be available in JBoss 3.2.4 (or
3.2.5), but you will most probably be able to just take the config file and
jgroups.jar from 3.2.4 and copy it to 3.2.1.
Yes, there is a listBindings method
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3832180#3832180
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
/fc.xml or fc-fast.xml, and convert them to the
format required by cluster-service.xml yourself.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3832172#3832172
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
r and update JBoss head
and 3.2.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3832016#3832016
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3832016
--
This cannot be done yet. Unless you use DB replication.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831426#3831426
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
You don't have a very aggressive STABLE layer, and no flow control. I suggest you
start out with fc.xml (from JGroups distro), and replace the bottom 2 protocols, minus
UNICAST.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831149#3831149
That's doable: change either mcast_addr or mcast_port, or both in cluster-service.xml
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3830890#3830890
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&
Can you try this with the latest JGroups and logging enabled (trace) for org.jgroups.*
?
This has not solved the problem, but I would be able to narrow the problem down.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3830093#3830093
Reply to
Does the NAKACK error only occur when the 2nd node is shunned, forced to leave the
cluster and the rejoins ? Does this happen *immediately* after rejoining (and failing
to get the state) ?
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3829726
Looks like this is a bug in JGroups with the STABLE message garbage collection
protocol.
You can increase the value of NAKACK.gc_lag to minimize the occurrence of this bug,
e.g. set it to 1000.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p
It should work
georgel wrote:
Hi,
I tried what you/Bela suggested in the other thread,
http://jboss.org/index.html?module=bb&op=viewtopic&t=47563
Server is JBoss 3.2.1, Linux, Java 1.4.2-b28. Got the following errors, and went back to the old configuration. Should your fix work for
exploded wars/sars are currently not supported (as stated in the docs).
Regards,
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827652#3827652";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&
Move your STABLE protocol on top of UNICAST, see cluster-service.xml in JBoss 3.2.4
for an example (or copy that config).
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827651#3827651";>View
the original post
http://www.jboss.org/index.html?module=bb&op=
n ObjectOutputStream each fille Arraylist produced 1.8kb of
data)
Same test, with ObjectMessages ? I have to conclude it is serialization then. Can you
do some intelligent marshalling of the vectors, and then use BytesMessage ?
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&
anonymous wrote : If I add that then it complains of another dependency:
| ChannelException: JChannel(): java.lang.Exception: Configurator.sanityCheck():
event GET_DIGEST_STATE is required by STATE_TRANSFER, but not provided by any of the
layers below
I see. Maybe hold off a bit more, until O
the pubsub test ? I'm also curious about HW/SW/JDK/NW.
For smaller messages (e.g. 1-2K), you should get at least 1000 msgs/sec.
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827465#3827465";>View
the original post
http://www.jboss.org/index.html?module=bb&am
radation. Maybe we're acking (postitive acks) messages, so
we're not really seeing async behavior ?
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827443#3827443";>View
the original post
http://www.jboss.org/index.html?module=bb&op=po
ernalization ? You mentioned you have ca 1-2K worth of data/msg ?
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827436#3827436";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827436>Reply
to the post
your
protocol specification
Hmm, it takes a bit of experimenting with this. Ovidiu, do you want to do it ?
Regarding state transfer: just add STATE_TRANSFER on top of your bare bones stack
(copy the tag from, say, fc-fast.xml).
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopi
JGroups distro, but I haven't tested it with
SLJMS.
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827317#3827317";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827317>Reply
to the post
-
e subscribers performance
seems to degrade.
|
| Perhaps if Bela could elucicate how I may optimize my protocol configuration for
this type of data distribution?
|
| Thanks.
Use the fc-fast protocol; I tested this on my home system, and got about 1600 msgs/sec.
fc-fast uses flow co
ServerlessJMS can be used inside JBoss, or standalone.
Yes, you should be able to integrate it easily into Tomcat.
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827123#3827123";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&
sCache) or HTTP
sessions. No in cases where you access JBossCache directly, because we
do expose the interface.
As I understand, LiveStore is a JDBC driver (or datasource), so that's a
level deeper in the hierarchy.
--
Bela Ban
Lead JGroups / JBossCache
Cell:
usly is not
something we want to be doing when we go to production.
| |
| |
Do you have the logs for this ? Also, can you post your cluster-service.xml ? You may
have to increase the values for FD, or use FD_SOCK instead.
Bela
http://www.jboss.org/index.html?module=bb&op=viewt
You could also call the stopService() method of ClusterPartition (via JMX), or use
jmx-console. startService() will cause it to rejoin the cluster again.
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826701#3826701";>View
the original post
http://www.jbos
Yes, for multihomed systems you need the bind_addr parameter.
Also, by enabling the logs (in log4j.xml) you might have seen what the problem was.
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826184#3826184";>View
the original post
http://www.jboss.org/inde
This is a known bug that was fixed in JGroups 2.2.1 on Feb 20 2004. This new release
is in JBoss head (JBoss 4.0) and the upcoming JBoss 3.2.4 (coming out in 1-2 weeks).
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825289#3825289";>View
the original post
http
Don't use the old impl; Ovidiu is working on a new implementation. He will post a
first prototype in 1-2 weeks (I'm actually playing with it as we speak).
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825004#3825004";>View
the original post
http:
That's
telnet localhost 1100, not
telnet 1100 !
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824048#3824048";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply
The 2nd node doesn't find the first one, so it thinks it is the first node and becomes
Singleton. Use the basic tests in JGroups to ensure the 2 members find each other.
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823857#3823857";>View
the original post
No, mainly because JCache is not yet out.
(I'm on the JCache JSR)
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823696#3823696
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&
dress (check /etc/hosts).
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823428#3823428
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823428
--
Lose the bind_addr=127.0.0.1.
I have some code that shows how to access the TreeCache MBean from servlets, I will
post a document soon.
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823392#3823392
Reply to the post :
http://www.jboss.org/in
inux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
--
Bela
config
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3822719#3822719
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3822719
---
SF.Net is
gards,
Bela
crobert wrote:
Hello,
I'm having the following clustering problem:
I have two JBoss 3.2.3 servers in a local network, clustering uses:
--> TCP and TCPGOSSIP with the following settings (in cluster-service.xml)
gossip_refresh_rate="1"
0 ? Also, try putting a list
of at least some of your servers in PROVIDER_URL. If none are found,
only then do we use multicast discovery.
--
Bela Ban
Lead JGroups / JBossCache
Cell: (408) 316-4459
---
SF.Net is sponsored by: Speed Start Yo
1 - 100 of 145 matches
Mail list logo