You should have a few choices.
1) If you have a laptop with wired and wireless connections, then you should
have two ip addresses.
2) You can define a loopback adapter on Windows as your second address.
3) You can work with a single ip address by using the JBoss service binding
manager.
I can advise about HA-JNDI. If you use the provider url of localhost:1100,
your context will be associated with HA-JNDI. If you then lookup objects via
that context, the lookup will utilize HA-JNDI. If you bind something using
that context, the binding will be stored in HA-JNDI and
JNDI (i.e., port 1099) will only perform the lookup on the local server's JNDI
bindings
HA-JNDI (i.e., port 1100) will search the following until the requested object
is located.
1) the cluster's HA-JNDI bindings
2) the local server's JNDI bindings
3) all other cluster servers' JNDI bindings
Sounded like a good suggestion ... but it didn't work. It doesn't appear that
dependencies in jboss-web.xml are being processed. Even if I define a
non-existent dependency in my war, no error is raised. I do see an error if I
define a non-existent dependency in an mbean definition.
I know
I've created JBCACHE-1025 to track this issue.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4037981#4037981
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4037981
___
jboss-user
Has anyone responded further to this issue. I just encountered it as well and
am now investigating.
The perplexing aspect of the problem is that the applicable JBoss mbean
registration code checks to ensure that the cache's mbean isn't registered
before it registers it. So you should never
Bela - the compatibility matrix indicates that you don't need the
-Djgroups.marshalling.compatible=true property setting if you're running
JGroups 2.4.x with JBossAS 4.0.5.GA. It does note that earlier versions of
JBossAS require the setting.
We're planning to use JGroups 2.4.1-SP1 with
Brian - this report appears to be correct. If you start a single instance of
JBoss 4.2 using the sample bindings, there's a conflict on port 4446. A quick
examination of the default bindings file shows that port 4446 is specified in
two different bindings for ports-default.
View the
I'm not clear on whether you're trying to access the
DistributedReplicantManager service remotely or if you're looking for something
else. Here's an example of how to use the DRM service remotely in JBoss 4.0.5.
Note that your remote client will need various JBoss jars on its classpath.
Sorry - I neglected to point out that this example uses JNDI to initially
access the mbean server. You'll need to configure an initial context to access
the server.
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
I think you understanding is correct; at least it matches mine. :)
I was unable to replicate your findings using JBoss 4.0.5. I used multiple IP
addresses rather than the service binding manager but I wouldn't think that
would matter. When I bound objects locally on both nodes and then
To bind something into the HAJNDI tree, you would obtain an initial context
specifying an HAJNDI port rather than a JNDI port. Anything that you bound
using that context would be placed in the HAJNDI tree and would only be
accessible via HAJNDI.
HAJNDI bindings are replicated to all nodes in
You can instantiate a multiplexer channel from a client as follows.
STACK_FILE = stacks.xml;
STACK_NAME = udp;
JChannelFactory factory=new JChannelFactory();
factory.setMultiplexerConfig(STACK_FILE);
Channel channel = factory.createMultiplexerChannel(STACK_NAME, foo);
channel.connect(my group);
I've used the separate ports approach (e.g., the binding file) successfully in
the past but stopped because I would frequently encounter problems which
required me to make changes to the port configurations.
For developers at least, using the IP address binding approach is generally
simpler.
Have you tried binding your server instances to IP addresses? If you're just
trying a two node cluster on your machine, you can probably use either a
wired/wireless combination or a wired/loopback combination.
The IP address approach is generally simpler as you don't have to create/use a
I wasn't aware of that bug.
I could be mistaken but I don't think you can use auto discovery to actually
bind something into HA-JNDI. If you want to bind explicitly into HA-JNDI, you
should add the HA-JNDI provider url to your context object. So you would add
an entry similar to the
One more observation - I took a look at the fix for JBAS-3260 and it stated
that the problem occurred when the HA-JNDI service wasn't deployed. So if
you're seeing this problem in JNDIView, are you running a clustered server?
View the original post :
The first thing you can do is confirm that you've bound the entry into HA-JNDI.
If you access the JNDIView mbean from the JMX Console, you can invoke the List
method and see if the entry is bound into the HA-JNDI namespace. If it's
there, then it should also be bound on your other server.
If
In JBossCache 1.4 and earlier, the cache's mbean has an Instance attribute
which provides a reference to the instance.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3989326#3989326
Reply to the post :
By remotely, I mean that you're not running in the same JVM. If you run your
code from a servlet deployed to JBoss, you'll be in the same JVM and I suspect
your code will work properly.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3986121#3986121
Reply to
Have you tried the lookup without the / character? If I define a data source
with a JNDI name of MySource, I can look it up in a servlet using
java:MySource.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3985941#3985941
Reply to the post :
Do all methods fail for your object name? Instead of using
server.getMBeanInfo(), try
Object retval = server.invoke(nameTest, listXML, null, null);
System.out.println(retval);
This should provide a listing of the JNDI tree contents.
View the original post :
I think the problem is that you're working remotely so you're accessing
proxies. Your original code will probably work as is if you execute it from a
servlet rather than a remote client.
Working remotely, you need to use methods such as server.invoke() and
server.getAttribute() to interact
You can see all the bindings by opening the JBoss JMX Console, selecting the
JNDIView service, and then invoking the list() method. This will show the
bindings for all your war files. You can also examine the source code for this
service to see how it locates the bindings.
View the original
The unit tests for statistics are located in org.jboss.cache.mgmt. The
MgmtCoreTest class is the one that tests puts, gets, evictions, etc.
I've only executed tests against TreeCache, not PojoCache (or TreeCacheAop).
AFAIK, there was no discussion of PojoCache when we implemented cache
If you see the CacheMgmtInterceptor mbean in your JBoss JMX Console display,
then UseInterceptorMbeans is definitely enabled.
The main TreeCache mbean (e.g., service=TreeCacheXX) and the
CacheMgmtInterceptor mbean both have attributes named Number of Nodes and
Number of Attributes. Are these
You might try looking at the JNDIView mbean on both servers to see if your SLSB
is still defined on each of them. If it is, then the problem may be occurring
because the SLSB is still registered in JNDI.
View the original post :
Attributes that are displayed in red with a NotSerializableException in
jconsole are probably correctly handled. Since jconsole is remote, it only
displays serializable attributes. In your example, the Instance attribute
represents the cache itself and the cache instance isn't serializable.
The operations error messages on the console seem to relate to the disabled
operations. It looks at first glance that these operations are the ones with
non-serializable parameters such as Fqn. The operations that take serializable
parameters such as String are enabled and seem to work
re: 3)
You might try debugging further by eliminating WebLogic and Spring from the
mix. You can try a standalone JBossCache client and see if jconsole will
display its mbeans successfully. How to do this is described in the TreeCache
user documentation under the section titled Accessing
JBoss Cache will register with an MBean server if you have statistics enabled.
You can disable this behavior by adding the following attribute to your JBoss
cache instance definition.
false
The statistics (e.g., hit/miss ratio) are dispalyed via interceptor mbeans that
are associated with
Sorry - my response needed to have HTML disabled. Here it is again.
false
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3960553#3960553
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3960553
Aargh! Reponse looks fine in preview mode but is wrong when displayed. Once
again.
lt;attribute name=UseInterceptorMbeansgt;falselt;/attributegt;
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3960555#3960555
Reply to the post :
Are you referring to the LoadBalancePolicy attribute in the HAJNDI service?
That's the only load balancing policy in the standard cluster-service.xml file.
If so, that policy is only used by HA-JNDI so overriding it will only affect
your use of HA-JNDI. By default, HA-JNDI lookups are directed
I'm not familiar with the installer so I don't know what servers it makes
available or what its advantages are. If you download the binary distribution
and unzip/tar it, you should end up with three server instances named
minimal, default and all. Create new server directories (e.g., node1,
35 matches
Mail list logo
