Clustered jndi replication

Does the replication in clustered jndi also support removing replicate
bindings
when you call unbind()?
When I programmatically bind a value (a String), it is replicated throughout
the cluster but when I try to unbind it only gets removed on one server.
Calling rebind with a new value doesn't work either; a message is printed to
the console saying there is a conflict. Has anyone seen this before and/or
is there
something I'm missing.
This is on weblogic5.1sp4.

This sounds like a bug.
I suggest that you file a bug report with our support organization. Be sure
to include a complete test case. They will also need information from
you -- please review our external support procedures:
http://www.beasys.com/support/index.html
Thanks,
Michael
Michael Girdley
BEA Systems Inc
"Jonathon Lee" <[email protected]> wrote in message
news:398b4219$[email protected]..
Does the replication in clustered jndi also support removing replicate
bindings
when you call unbind()?
When I programmatically bind a value (a String), it is replicatedthroughout
the cluster but when I try to unbind it only gets removed on one server.
Calling rebind with a new value doesn't work either; a message is printedto
the console saying there is a conflict. Has anyone seen this beforeand/or
is there
something I'm missing.
This is on weblogic5.1sp4.

Similar Messages

Cluster-wide JNDI replication

I have a question about cluster wide JNDI replication. I am on weblogic
          7.0 sp2, solaris 8. I have 2 weblogic servers in a cluster and two
          asynchronous JVM's connect to this cluster. The two weblogic servers
          would be w1 and w2 and the JVMs would be j1
          w1 creates a stateful ejb. The handle to this ejb is put on the JNDI
          tree. A JMS message is created which contains the key to the handle
          object. A JMS message is sent which is picked up by one of the JVM's say
          j1. j1 tries to do a lookup of the handle using the key in the JMS
          message and it is not able to find the handle object.
          The reason is that j1 is trying to connect to the w2 to find the handle.
          The change to the jndi tree is not propagated to w2 yet and hence the
          error. Any ideas on why it would take so long to communicate the jndi
          tree? My jndi tree has hardly anything in it. There are a couple of JMS
          connection factories and 3 ejbs and couple of JMS queues.
          Would appreciate any kind of help. I am going to migrate storing the ejb
          handles to another persistent store instead of the jndi tree but till
          then any insight into this problem would be helpful.
          Please don't advice solutions like using Thread.sleep and trying again
          Thanks,
          Shiva.


Shiva,
          > I have a question about cluster wide JNDI replication. I am on weblogic
          > 7.0 sp2, solaris 8. I have 2 weblogic servers in a cluster and two
          > asynchronous JVM's connect to this cluster. The two weblogic servers
          > would be w1 and w2 and the JVMs would be j1
          >
          > w1 creates a stateful ejb. The handle to this ejb is put on the JNDI
          > tree. A JMS message is created which contains the key to the handle
          > object. A JMS message is sent which is picked up by one of the JVM's say
          > j1. j1 tries to do a lookup of the handle using the key in the JMS
          > message and it is not able to find the handle object.
          >
          > The reason is that j1 is trying to connect to the w2 to find the handle.
          > The change to the jndi tree is not propagated to w2 yet and hence the
          > error. Any ideas on why it would take so long to communicate the jndi
          > tree? My jndi tree has hardly anything in it. There are a couple of JMS
          > connection factories and 3 ejbs and couple of JMS queues.
          That's an interesting problem. The handle should have enough information
          to locate the EJB. Are you explicitly trying to connect to W2 from J1 or
          something? That part didn't make sense to me.
          (While it's a different approach, if you need to share data real-time in a
          cluster, use our Coherence Java clustered cache software.)
          Peace,
          Cameron Purdy
          Tangosol, Inc.
          http://www.tangosol.com/coherence.jsp
          Tangosol Coherence: Clustered Replicated Cache for Weblogic
          "Shiva P" <[email protected]> wrote in message
          news:[email protected]...
          >

JNDI replication\lookup problems

          Hi,
          We have a WL5.1 SP12 cluster that until today consisted of 2 Solaris boxes running
          8 WL instances on the 2.6 OS.
          Today we attempted to add a third Solaris box, running 2 SP12 WL instances on the
          2.8 OS. These two new instances were identical to the other 8 in all respects apart
          from one ejb jar which they did not deploy (because of Solaris 2.8\JNI\JDK1.3.1 incompatiblilities).
          We figured that these new JVM could lookup this bean via the clustered JNDI and execute
          on one of the original 8 JVMs, so we did not deploy on these new servers. This worked
          fine on test (a 3 way cluster, on one box running Solaris 2.8 and SP10).
          However when we cut the new box in this morning we got javax.naming.NameNotFoundExceptions
          from the new JVMs.
          These new JVMs apeared to start fine, and everything looked as it should on the console,
          but still the error.
          so :
          what could it be :
          OS related - a clustering spanning 2.6 and 2.8 OSs
          SP 12 related ?
          Anybody encountered anything like this before ?
          Thanks in advance.
          Justin


          Yes, the EJB classes are in the server classpath.
          I assumed that JNDI replication occured as a resulting of enabling clustering.
          "Sabha" <[email protected]> wrote:
          >Are the ejb home/remote interfaces in the server classpath of the 2 newer
          >JVMs? Is jndi replication turned off?
          >
          >-Sabha
          >
          >"Justin" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Hi,
          >>
          >> We have a WL5.1 SP12 cluster that until today consisted of 2 Solaris boxes
          >running
          >> 8 WL instances on the 2.6 OS.
          >>
          >> Today we attempted to add a third Solaris box, running 2 SP12 WL instances
          >on the
          >> 2.8 OS. These two new instances were identical to the other 8 in all
          >respects apart
          >> from one ejb jar which they did not deploy (because of Solaris
          >2.8\JNI\JDK1.3.1 incompatiblilities).
          >> We figured that these new JVM could lookup this bean via the clustered
          >JNDI and execute
          >> on one of the original 8 JVMs, so we did not deploy on these new servers.
          >This worked
          >> fine on test (a 3 way cluster, on one box running Solaris 2.8 and SP10).
          >>
          >> However when we cut the new box in this morning we got
          >javax.naming.NameNotFoundExceptions
          >> from the new JVMs.
          >>
          >> These new JVMs apeared to start fine, and everything looked as it should
          >on the console,
          >> but still the error.
          >>
          >> so :
          >>
          >> what could it be :
          >>
          >> OS related - a clustering spanning 2.6 and 2.8 OSs
          >> SP 12 related ?
          >>
          >> Anybody encountered anything like this before ?
          >>
          >> Thanks in advance.
          >>
          >> Justin
          >>
          >>
          >>
          >
          >

JNDI replication within a cluster

Hi to all of you,
we successfully enabled HTTP Session replication and tested the failover. We would also like to setup a JNDI replication, so that we can use it as a storage for some shared data -- as stated in http://download.oracle.com/docs/cd/B10464_05/web.904/b10324/cluster.htm this should be enabled automatically, once EJB replication is enabled.
With some problems we finally enabled EJB replication (we configured it through orion-application.xml) and the required replication policy is propagated to our statful beans. Anyway, the JNDI is still not replicated over the machines.
We are running latest OAS 10g, cluster is MultiCast on RedHat Enterprise, replication policy for Stateful beans is set to 'onRequestEnd' (we tried all the options :), our application is normal ear with 1 ejb and 1 war archive and apart from JNDI replication, it works as expected.
Is there some trick that is not mentioned or that we may overlooked in documentation to enable JNDI replication?
Kind Regards,
Martin

Hopefully solved -- though the documentation explicitly mentions rebinding as not working, after any changes made to value stored in JNDI context you should just re-bind the value to the JNDI context; the value is replicated to other JNDI contexts.
m.

JNDI replication in cluster

Is there a way to force the JNDI replication?


It is on by default, unless you specifically disabled it:
          http://e-docs.bea.com/wls/docs61/javadocs/weblogic/jndi/WLContext.html
          REPLICATE_BINDINGS
          public static final java.lang.String REPLICATE_BINDINGS
          Cluster-specific: Specifies whether tree modifications are replicated
          and is only applicable when connecting to WebLogic Servers that are running
          in a cluster. By default, any modification to the naming tree is replicated
          across the cluster, which ensures that any server can act as a naming server
          for the entire cluster. Setting this property to false changes this behavior
          and should be done with extreme caution: a false setting means that modifications
          to the tree caused by bind, unbind, createSubcontext, and destroySubcontext
          will not be replicated.
          Understand the implications of this property before changing its default (true).
          Pothiraj <[email protected]> wrote:
          > Is there a way to force the JNDI replication?
          Dimitri

JNDI replication problems in WebLogic cluster.

I need to implement a replicable property in the cluster: each server could
update it and new value should be available for all cluster. I tried to bind
this property to JNDI and got several problems:
1) On each rebinding I got error messages:
<Nov 12, 2001 8:30:08 PM PST> <Error> <Cluster> <Conflict start: You tried
to bind an object under the name example.TestName in the jndi tree. The
object you have bound java.util.Date from 10.1.8.114 is non clusterable and
you have tried to bind more than once from two or more servers. Such objects
can only deployed from one server.>
<Nov 12, 2001 8:30:18 PM PST> <Error> <Cluster> <Conflict Resolved:
example.TestName for the object java.util.Date from 10.1.9.250 under the
bind name example.TestName in the jndi tree.>
As I understand this is a designed behavior for non-RMI objects. Am I
correct?
2) Replication is still done, but I got randomly results: I bind object to
server 1, get it from server 2 and they are not always the same even with
delay between operation in several seconds (tested with 0-10 sec.) and while
it lookup returns old version after 10 sec, second attempt without delay
could return correct result.
Any ideas how to ensure correct replication? I need lookup to return the
object I bound on different sever.
3) Even when lookup returns correct result, Admin Console in
Server->Monitoring-> JNDI Tree shows an error for bound object:
Exception
javax.naming.NameNotFoundException: Unable to resolve example. Resolved: ''
Unresolved:'example' ; remaining name ''
My configuration: admin server + 3 managed servers in a cluster.
JNDI bind and lookup is done from stateless session bean. Session is
clusterable and deployed to all servers in cluster. Client invokes session
methods throw t3 protocol directly on servers.
Thank you for any help.

It is not a good idea to use JNDI to replicate application data. Did you consider
using JMS for this? Or JavaGroups (http://sourceforge.net/projects/javagroups/) -
there is an example of distibuted hashtable in examples.
Alex Rogozinsky <[email protected]> wrote:
I need to implement a replicable property in the cluster: each server could
update it and new value should be available for all cluster. I tried to bind
this property to JNDI and got several problems:
1) On each rebinding I got error messages:
<Nov 12, 2001 8:30:08 PM PST> <Error> <Cluster> <Conflict start: You tried
to bind an object under the name example.TestName in the jndi tree. The
object you have bound java.util.Date from 10.1.8.114 is non clusterable and
you have tried to bind more than once from two or more servers. Such objects
can only deployed from one server.>
<Nov 12, 2001 8:30:18 PM PST> <Error> <Cluster> <Conflict Resolved:
example.TestName for the object java.util.Date from 10.1.9.250 under the
bind name example.TestName in the jndi tree.>
As I understand this is a designed behavior for non-RMI objects. Am I
correct?
2) Replication is still done, but I got randomly results: I bind object to
server 1, get it from server 2 and they are not always the same even with
delay between operation in several seconds (tested with 0-10 sec.) and while
it lookup returns old version after 10 sec, second attempt without delay
could return correct result.
Any ideas how to ensure correct replication? I need lookup to return the
object I bound on different sever.
3) Even when lookup returns correct result, Admin Console in
Server->Monitoring-> JNDI Tree shows an error for bound object:
Exception
javax.naming.NameNotFoundException: Unable to resolve example. Resolved: ''
Unresolved:'example' ; remaining name ''
My configuration: admin server + 3 managed servers in a cluster.
JNDI bind and lookup is done from stateless session bean. Session is
clusterable and deployed to all servers in cluster. Client invokes session
methods throw t3 protocol directly on servers.
Thank you for any help.--
Dimitri

Clustering JNDI

Hi,
As I'm using clustering of weblogic 7.0, and I know I cannot use ServletContext
for placing objects as it's not replicated via all the servers, I wondered if
I could use Context for that.
If I place objects in the JNDI Context using bind, and I update them using rebind,
will those object and changes be clustered to every node? What should I do for
changes to be propagated?
Does the server's perfomance suffer too much from changing use of JNDI instead
of ServletContext?
Is there any problem for concurrent access to objects in JNDI Context?
I know there's a product called Coherence by Tangosol for using ServletContext
in clustered environments, but I cannot use it as my client does not wanna hear
about more products to be bought. :.-(
Thanks

"Ignacio Sanchez" <[email protected]> wrote in message news:<[email protected]>...
Thanks for your reply,
Anyway, I see one big problem, which is included in that page, in the warning.
Here it is: "Do not use the cluster-wide JNDI tree as a persistence or caching
mechanism for application data. Although WebLogic Server replicates a clustered
server instance's JNDI entries to other server instances in the cluster, those
entries are removed from the cluster if the original instance fails".
So, this does not seem to be the solution.
"SIPTech Community" <[email protected]> wrote:
"Ignacio Sanchez" <[email protected]> wrote:
Hi,
As I'm using clustering of weblogic 7.0, and I know I cannot use ServletContext
for placing objects as it's not replicated via all the servers, I wondered
if
I could use Context for that.
If I place objects in the JNDI Context using bind, and I update them
using rebind,
will those object and changes be clustered to every node? What should
I do for
changes to be propagated?
Does the server's perfomance suffer too much from changing use of JNDI
instead
of ServletContext?
Is there any problem for concurrent access to objects in JNDI Context?
I know there's a product called Coherence by Tangosol for using ServletContext
in clustered environments, but I cannot use it as my client does not
wanna hear
about more products to be bought. :.-(
ThanksHi,
Every server instance in a cluster maintains Clusterwide JNDI Tree
(for clustered
objects).
Binded objects in any cluster server instance will be replicated
in other
server instances just after successful
binding.
Pls. view this URL for more details :
http://edocs.bea.com/wls/docs70/cluster/features.html#1007508
Prema
Many Application Servers make use of caching for the JNDI Tree when
you have more than 1 clone (vertical or horizontal).
If you make use of JNDI in order to store "constant" information, you
need to use just bind /rebind and lookup... but if you want update
frequently a JNDI object you will have to clean this cache by setting
the appropriate property in the JNDI Environment... because you could
experience a dirty (old) value by making a simple lookup.
A sample using IBM WebSphere:
public static final Object lookupEnvEntry(InitialContext ic, String
entryName, boolean clearCache) {
     try {
          if (clearCache) {
               Hashtable env = ic.getEnvironment();
               env.put("com.ibm.websphere.naming.jndicache.cacheobject",
"cleared");
               ic = new InitialContext(env);
          return (String)ic.lookup(entryName.trim());
     } catch (Exception ex) {
          System.out.println("Initial Context: Error retrieving Environment
Entry: " + entryName.trim() + " - " + ex.getMessage());
          return null;

Re: Clustering & JNDI

The JNDI documentation says that only Remote objects can be replicated.
          Excerpts from WL jndi doc:
          Note that you cannot reliably use the naming service to replicate objects.
          For example, if you bind an RMI object "myReplicatedObject" into a
          cluster-wide JNDI tree, and "myReplicatedObject" from Server One places a
          serializable -- but not Remote -- object "myDataObject" into the JNDI tree,
          that unRemoted object does not get replicated to other servers in the
          cluster. If Server One fails and a client calls "myReplicatedObject," the
          RMI service will be available, but its "myDataObject" will not.
          If you need to guarantee access to some data that is produced or used by a
          replicated object, you should store the data in a database so that it can be
          reached by any server in the cluster that is hosting the replicated service.
          An example of this is an entity EJBean.
          Sam Jacob
          GiriBabu <[email protected]> wrote in message
          news:[email protected]...
          > Hi,
          >
          > Has anyone tried putting data objects in a JNDI tree, and then setting
          > up the servers in a clustered environment. The behavior I am seeing is
          > strange.
          >
          > Goal: To cache the same data in all the servers in a cluster
          >
          > Proposed Solution: Put the data in the JNDI tree, so that clients can
          > do a lookup and get the data. Since WL does not synchronize data across
          > the servers in a cluster, manually synchronize all the JNDI trees.
          >
          > In the prototype, I have a startup class, which populates the JNDI tree
          > on the URL passed in as an argument. The startup class is registered in
          > the Cluster-wide properties file.
          >
          >
          > After implementing the prototype, this is the bahaviour I see
          >
          > If I kill one of the servers, the client gets an exception, when he does
          > a lookup on a live server.
          >
          > It appears that the dying server is taking away all the JNDI entries
          > that it put in its JNDI tree, from all the other JNDI trees in the
          > cluster too.
          >
          >
          > Am I assuming something wrong? I want to create separate copies of the
          > data objects in each JNDI tree.
          >
          > Thanks ,
          > Vijay
          >
          >
          >
          >
          >
          >
          >


Sam wrote:
          > The JNDI documentation says that only Remote objects can be replicated.
          > Excerpts from WL jndi doc:
          > Note that you cannot reliably use the naming service to replicate objects.
          > For example, if you bind an RMI object "myReplicatedObject" into a
          > cluster-wide JNDI tree, and "myReplicatedObject" from Server One places a
          > serializable -- but not Remote -- object "myDataObject" into the JNDI tree,
          > that unRemoted object does not get replicated to other servers in the
          > cluster. If Server One fails and a client calls "myReplicatedObject," the
          > RMI service will be available, but its "myDataObject" will not.
          >
          > If you need to guarantee access to some data that is produced or used by a
          > replicated object, you should store the data in a database so that it can be
          > reached by any server in the cluster that is hosting the replicated service.
          > An example of this is an entity EJBean.
          >
          >
          > Sam Jacob
          >
          An entity bean is always a good option, but what happens if you want to
          replicate the information in memory for the highest performance?

CF7 Clustering - session replication broken

Further to my
earlier
thread on CF7 clustering and the "network error",
I think session replication is broken. True, I can't find any
documentation which explains how it is supposed to behave, but this
is what I'm seeing:
If you have a two node cluster, and person A has a session on
node 1 and person B a session on node 2, session variables for each
user DO NOT appear on both nodes
Sessions on one node will only appear on the other when the
first node fails over
Moreover, they will only appear when the user makes another
request
CFLOGIN, when using loginstorage="session" does not replicate.
This means you have to use sticky sessions, and if there is a node
failure, the user will have to login in again. This can be avoided
by using loginstorage = "cookie" but this means the username and
password are stored unencrypted in the cookie.
Problems I have with this:
It's impossible to have a cluster wide view of sessions. E.g.
you can't count how many sessions you have at any one time. Any
code that makes use of being able to dig in to multiple sessions -
made possible by J2EE sessions - will not work reliably.
CFLOGIN is broken. It would be better to not use it for sites
that have to be secure as keeping the unencrypted username and
password in a cookie is very insecure. The only way to protect the
username and password being stored in the cookie is SSL; and that
means that every single item on the site needs to be protected by
SSL to stop the browser from serving up the cookie over an
unprotected connection.
It's not clear what is responsible for replication. If sessions
are only replicated when an instance goes down, rather than
continously, then I assume that the master instance of CF on each
server is responsible for replication. What happens if the server
crashes?

Information about session replication can be found here: http://docs.oracle.com/cd/E21764_01/web.1111/e13709/failover.htm#i1024620
it contains a section 'Requirements for HTTP Session State Replication' that might be helpful to you.
Also important to note is, how the load balancer handles session binding and the WebLogic cookie
http://docs.oracle.com/cd/E21764_01/web.1111/e13709/load_balancing.htm#i1026939

Clustering/Session Replication

Hi,
I know that's a fairly basic question, but I just want to make sure I am not missing anything here.
We have an application which runs on a cluster of WebLogics and the user sometimes is requested to sign in again (it seems like it hit another instance and the session is not there).
The admins from Weblogic say there is NO WAY to disable Session Replication when running Weblogic in a cluster, which makes total sense. They say, however, that if the application doesn't serialize its session, then Weblogic can't handle the serialization. In short, they say it's an application issue.
The developers say the application is written properly, and that the problem is in Weblogic's side.
Although I am still a developer (for my own projects), my role here doesn't allow me to look into the code, how can I show the developers that WebLogic is setup correctly and that they need to fix their code?
Regards

Information about session replication can be found here: http://docs.oracle.com/cd/E21764_01/web.1111/e13709/failover.htm#i1024620
it contains a section 'Requirements for HTTP Session State Replication' that might be helpful to you.
Also important to note is, how the load balancer handles session binding and the WebLogic cookie
http://docs.oracle.com/cd/E21764_01/web.1111/e13709/load_balancing.htm#i1026939

URL Resource and JNDI Replication

Do URLResources get replicated in the JNDI tree?

JDBC resource can be created using asadmin command.
Its a two step process.
First JDBC connection pool has to be created using following command.
asadmin create-jdbc-connection-pool user admin password adminadmin host fuyako port 7070 datasourceclassname XA restype jax.sql.DataSource
isolationlevel serializable isconnectvalidatereq=true validationmethod auto-commit description "XA Connection" --property DatabaseName="jdbc\:pointbase\:server\:\/\/local
host\/sample" :User=public:Password=public XA_connection_pool
Next JDBC resource has to be created using the following command.
asadmin create-jdbc-resource --user admin --password adminadmin --host fuyako --port 7070
--connectionpoolid XA_connection_pool --description
"creating a sample jdbc resource" sample_jdbc_resource
Please change the parameters as suitable to you.
The detailed description of these commands can be found as following URLs
http://java.sun.com/j2ee/1.4/docs/relnotes/cliref/hman1/create-connector-connection-pool.1.html
http://java.sun.com/j2ee/1.4/docs/relnotes/cliref/hman1/create-jdbc-resource.1.html

JNDI replication and rebinging from multiple servers

Here is what I need:
Server1 binds ObjX to it's JNDI tree (which replicates the object to the
other servers in the cluster)
Server2 does a lookup on ObjX, changes some values and rebinds it back to
it's JNDI tree (which should replicate the changes to the other servers
including Server1).
The above does not happen because, Server1 is known to be the owner of ObjX,
and thus instead of getting replicated data after Server2 rebinds, it gets
duplicate name errors.
Is there anyway to make the above work the way I want it to?

It is bad to use JNDI to replicate application data/cache in the cluster.
If you are sure that you want to use multicast to replicate your data,
in 6.0 you can use JMS:
http://e-docs.bea.com/wls/docs60/jms/implement.html#1206428
Or you can use javagroups: http://sourceforge.net/projects/javagroups
John Boyd <[email protected]> wrote:
Yes, exactly.
"Dimitri Rakitine" <[email protected]> wrote in message
news:[email protected]..
Are you trying to use JNDI to replicate runtime data across the cluster?
John Boyd <[email protected]> wrote:
Here is what I need:
Server1 binds ObjX to it's JNDI tree (which replicates the object to the
other servers in the cluster)
Server2 does a lookup on ObjX, changes some values and rebinds it back
to
it's JNDI tree (which should replicate the changes to the other servers
including Server1).
The above does not happen because, Server1 is known to be the owner of
ObjX,
and thus instead of getting replicated data after Server2 rebinds, itgets
duplicate name errors.
Is there anyway to make the above work the way I want it to?--
Dimitri
Dimitri

Clustering: Context Replication

I want to find out how to replicate context attributes in clustering
environment.
Looks like i can do the same stuff with Tomcat, but couldn't find the way to
do in Sun Application Server
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster.html
The application server i'm using is Sun Java Enterprise System 8.1.
Thanks in advance.
TW

I now know it can't be done.

Connecting two Coherence Clusters using Replication

I am using: http://wiki.tangosol.com/pages/viewpage.action?pageId=1343616 to setup the "Replicated-site Coherence*Extend Example". On running the build I am getting errors as shown below. Can anyone help me to resolve this so that I can get the example up and running?
.\..\src\com\tangosol\examples\extend\ExtendReadWriteBackingMap.java:57: cannot find symbol
symbol : constructor ReadWriteBackingMap(com.tangosol.net.BackingMapManagerContext,com.tangosol.util.ObservableMap,java.util.Map,com.tangosol.net.cache.CacheStore,boolean,int)
location: class com.tangosol.net.cache.ReadWriteBackingMap
super(ctxService, mapInternal, mapMisses, store, fReadOnly,
^
.\..\src\com\tangosol\examples\extend\ExtendReadWriteBackingMap.java:85: incompatible types
found : com.tangosol.net.cache.ReadWriteBackingMap.CacheStoreWrapper
required: com.tangosol.net.cache.CacheStore
CacheStore store = getCacheStore();
^
.\..\src\com\tangosol\examples\extend\ExtendReadWriteBackingMap.java:153: storeAllInternal(java.util.Set) in com.tangosol.net.cache.ReadWriteBackingMap.CacheStoreWrapper cannot be applied to (java.util.Map)
super.storeAllInternal(mapEntries);
^
3 errors
On running javac in verbose mode it does show that the classes in coherence.jar have been loaded, especially the one required:
[loading com\tangosol\net\cache\ReadWriteBackingMap.class(com\tangosol\net\cache:ReadWriteBackingMap.class)]
[loading com\tangosol\net\cache\ReadWriteBackingMap$CacheStoreWrapper.class(com\tangosol\net\cache:ReadWriteBackingMap$CacheStoreWrapper.class)]

I am running with Java: jdk1.6.0_21, Coherence: 3.6 and ant: 1.8. Nb. I am running on Windows but that should not matter....
I thought it could be a problem with ant not passing in the correct classpaths or somehting similar so I wrote the equivalent DOS script (shown below) to run the build but still got the same error.
Nb. I have managed to run the synchronized site example with the above java, coherence and ant versions.
build.cmd_
@echo off
if "%1"=="build" goto build
if "%1"=="clean" goto clean
goto help
:help
echo "usage: build.cmd build"
echo build: makes the clases directory and compiles the java
echo clean: removes the classes directory
goto exit
:build
mkdir .\..\classes
"%JAVA_HOME%"\bin\javac -d .\..\classes -cp "%COHERENCE_HOME%"\lib\coherence.jar .\..\src\com\tangosol\examples\extend\*.java -verbose
goto exit
:clean
rmdir .\..\classes /q/s
goto exit
:exit
"%JAVA_HOME%" = "C:\Program Files\java\jdk1.6.0_21"
"%COHERENCE_HOME%" = "C:\Program Files\Oracle\coherence-java-3.6.0.0b17229\coherence"
Edited by: Ku on Sep 21, 2010 11:37 AM
Added info to show location of java/coherence variables.

How many clusterable things in JNDI tree?

We're starting to try out clustering in WL 5.1 (sp8 on WinNT for now) We're
          seeing some odd behavior and we're wondering if the cause is related to JNDI
          replication messages. If we deploy just a couple of clusterable rmi
          services on two servers in a cluster, things seem to work ok. They maintain
          a connection to each other and can be viewed with the Admin console.
          However, if we deploy about 200 clusterable things (mostly EBs that by
          default have clusterable homes) then things get weird. If we just bring up
          one server, things aren't too bad. But when we bring up the second server,
          communication between the two servers is only established briefly before we
          get a "Timed out server" or something worse.
          Someone thought they had read a news post saying that it's not good to have
          large number of clusterable things in the JNDI tree because of all the
          replication messages caused by this. True? How many is too many? Thanks.


JNDI replication messages only occur when the state of the JNDI tree changes --
          which is normally at server startup or shutdown. I would recommend pursuing
          this with support as I have been at sites that deployed more EJBs in a cluster
          than this without those problems.
          Joe Herbers wrote:
          > We're starting to try out clustering in WL 5.1 (sp8 on WinNT for now) We're
          > seeing some odd behavior and we're wondering if the cause is related to JNDI
          > replication messages. If we deploy just a couple of clusterable rmi
          > services on two servers in a cluster, things seem to work ok. They maintain
          > a connection to each other and can be viewed with the Admin console.
          >
          > However, if we deploy about 200 clusterable things (mostly EBs that by
          > default have clusterable homes) then things get weird. If we just bring up
          > one server, things aren't too bad. But when we bring up the second server,
          > communication between the two servers is only established briefly before we
          > get a "Timed out server" or something worse.
          >
          > Someone thought they had read a news post saying that it's not good to have
          > large number of clusterable things in the JNDI tree because of all the
          > replication messages caused by this. True? How many is too many? Thanks.

Clustered jndi replication

Similar Messages

Maybe you are looking for