Can you add the a line to your/a log4j properties files that lowers the
debug level? It would look like:

log4j.category.com.opensymphony.oscache=DEBUG


On Wed, 2004-04-21 at 07:58, Enrique Medina wrote:
> Hi,
> 
> I have developed a web application with OJB, as the ORM for data access. But 
> now, I want to use OJB in a clustered environment. I have read with 
> attention the information provided at the web:
> 
> http://db.apache.org/ojb/howto-work-with-clustering.html
> 
> with respect to setting up OSCache to work with OJB in a cluster. I have 
> strictly followed all the steps commented in this tutorial, and have made a 
> little client test application to see the results. Everything seems to start 
> perfectly, but no cache communication exists between two instances of this 
> client test application at all!
> 
> I am using OJB RC6 with latest version of OSCache & JavaGroups deployed 
> within OSCache distribution. I have a simple test application consisting of:
> 
> 1  public static void main(String[] args)
> 2  {
> 3     // Obtain a connection through OJB broker.
> 4     PersistenceBroker broker = 
> PersistenceBrokerFactory.defaultPersistenceBroker();
> 5
> 6     // Create a new query by example that should return all clients.
> 7     Query query = QueryFactory.newQueryByExample(new ClientVO());
> 8     Collection clients = broker.getCollectionByQuery(query);
> 9
> 10    // Ask again for the collection of clients.
> 11    Collection againClients = broker.getCollectionByQuery(query);
> 12 }
> 
> I set a breakpoint on lines 8 and 11, just before obtaining the clients for 
> the first time and for the second time.
> 
> The sequence of steps I follow to see if two instances of the program 
> communicate at cache level through JavaGroups are:
> 
> 1) I run a first instance of this test application
>     1.1) The thread of execution gets stopped on line 4 (first instance). 
> The JavaGroups logging says -- A new member at address '192.168.0.1:1590' 
> has joined the cluster
> 
> 2) Then I run a second instance of the application
>     2.1) The thread of execution gets stopped on line 4 (second instance). I 
> see on the console how the first instance is notified that the second 
> instance has joined the cluster (JavaGroups logging -- A new member at 
> address '192.168.0.1:1593' has joined the cluster).
> 
>     1.2) I obtain the collection of clients for the first time on first 
> instance, so all the object are cached.
> 
>     2.2) I obtain the collection of clients for the first time on second 
> instance. But objects are not retrieved from the cache (which is supposed to 
> be shared with the first instance); instead they are cached again (as if it 
> was a local cache for the instance).
> 
>     1.3) I obtain again the collection of clients for the second time on 
> first instance. Now the objects are retrieved from the cache (but as a local 
> cache only available to the first instance)
> 
>     2.3) I obtain again the collection of clients for the second time on 
> second instance. Now the objects are retrieved from the cache (but as a 
> local cache only available to the second instance).
> 
> So this is my simulation of a clustered environment with two instances of 
> the same test application. And of course I don't get the behaviour I 
> expected to.
> 
> Am i doing something worng? And I missunderstanding something? Can this kind 
> of test be done, as reflected on the documentation from OJB web?
> 
> Patiently observing the console, it seems that on every instance a new 
> JavaGroups broadcasting listener is created:
> 
> INFO [main] (Config.java:146) - Properties 
> {cache.algorithm=com.opensymphony.oscache.base.algorithm.LRUCache, 
> cache.capacity=1000, cache.unlimited.disk=false, 
> cache.event.listeners=com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener}
> INFO [main] (GeneralCacheAdministrator.java:98) - Constructed 
> GeneralCacheAdministrator()
> INFO [main] (GeneralCacheAdministrator.java:293) - Creating new cache
> INFO [main] (AbstractBroadcastingListener.java:35) - 
> AbstractBroadcastingListener registered
> INFO [main] (JavaGroupsBroadcastingListener.java:91) - Starting a new 
> JavaGroups broadcasting listener with 
> properties=UDP(mcast_addr=231.12.21.132;mcast_port=45566;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_SOCK:VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):pbcast.STABLE(desired_avg_gossip=20000):UNICAST(timeout=5000):FRAG(frag_size=8096;down_thread=false;up_thread=false):pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=true)
> 
> -------------------------------------------------------
> GMS: address is 192.168.0.1:1590
> -------------------------------------------------------
> INFO [main] (JavaGroupsBroadcastingListener.java:99) - JavaGroups clustering 
> support started successfully
> INFO [PullPushAdapterThread] (JavaGroupsBroadcastingListener.java:166) - A 
> new member at address '192.168.0.1:1590' has joined the cluster
> 
> so this can be maybe the problem ... But I confess I have no idea ...
> 
> Thanks in advance,
> Enrique Medina.
> 
> _________________________________________________________________
> Correos m�s divertidos con fotos y textos incre�bles en MSN 8. Pru�balo 
> gratis dos meses. http://join.msn.com/?pgmarket=es-es&XAPID=45&DI=1055
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to