You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Horton Simon <Si...@uk.mizuho-sc.com> on 2006/02/24 10:43:14 UTC
RE: RemoteCacheFactory problem 'WARNING: Error while running event
from Queue:' ?
Hi Aaron,
Thanks for your quick response and detailed explanation. From your
explanation I understand now that this message relates to the PutEvent
failing between the remote server and the original dead client process.
I was thinking that the following log messages applied to the
communication between my new client process and the remote server, as
the log messages occurred on the remote process when my new client
initiated its PutEvent.
23-Feb-2006 16:04:01
org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent run
INFO: Error while running event from Queue: PutEvent for key: city123
value: null. Retrying...
....
23-Feb-2006 16:04:31
org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent run
WARNING: Error while running event from Queue: PutEvent for key: city123
value: null. Dropping Event and marking Event Queue as non-functional.
I see now that it is not a problem.
I think it would be helpful if those INFO and WARNING messages also
included the listener and cacheName information e.g. [listenerId=0,
cacheName=testCache1], as occurs in some of the other messages. This
would make it clear that the messages were to do with the original dead
client process rather than the new client process.
Also, to answer your questions regarding versions and how I'm running
the remote process. I am running the latest code 1.2.7.0 and my Remote
RMI server is running in standalone mode.
Thanks for your assistance.
Best wishes,
Simon
-----Original Message-----
From: Aaron Smuts [mailto:asmuts@yahoo.com]
Sent: 24 February 2006 00:53
To: JCS Users List
Subject: Re: RemoteCacheFactory problem 'WARNING: Error while running
event from Queue:' ?
A point of clarification. The remote cache server can
be embedded, but it won't necessarily do what you
want.
The remote cache server sits on top of the cache. It
does not sit inside the cache as an auxiliary. When
you cluster remote cache servers, the clusters talk to
each other through the cache. Basically, the client
is an auxiliary like any other. If it is marked as
clustered, this means that it can have special
behaviorial consequences. If an update comes from a
cluster client, then the data is only sent to the
receiver's other clients if local cluster consistency
is set to true.
If an item comes into the server, the local cache (the
server's cache) will be updated, but not vice versa.
Puts into the remote server's cache will not make it
to the server, which is responsible for broadcasting.
Hence, you can charge a remote server from within, but
you cannot make it send through the cache. You could
call send directly . . .
Aaron Smuts
--- Aaron Smuts <as...@yahoo.com> wrote:
> Am I correct that all you are concerned with is the
> warning?
>
> The remote cache is logging that the client
> registered
> as #1 is no longer reachable. This is the correct
> behavior. Ideally, the client would deregister
> itself
> . . .
>
> The remote cache server has a bunch of queues. For
> each region that is registered, a list of exported
> remote cache listener objects is kept in a list.
> When
> an item is put into a region on the remote server,
> the
> remote server gets the list of listeners and then
> updates all the listeners that are not the source of
> the update. Every update contains a listener id.
> This is assigned by the server. The listener needs
> an
> id so the remote cache knows who not to update.
>
> When you start the client for the first time it
> registers with the server. If it is the first
> client
> to ever register it will be assigned 1. It tells
> the
> server what regions it is interested in. The remote
> cache adds the listener to the list for each region
> that the client is interested in.
>
> Killing the client and then restarting it results in
> the client trying to register with the server again,
> as it must. If this is the second registation the
> server has received, the client will be assigned id
> 2.
> If you then put something into the cache, the
> client
> sends it to the server, and the server processes it.
>
> It gets the list of listeners for the region. This
> list now contains two entries. (It has no way to
> know
> at this point that the first reference is no longer
> reachable.) When it tries to send to the first
> listener it will discover the error. It retries 10
> times or so and then if the client is still not
> reachable, it quits.
>
> The newly registered client should be alive and
> healthy.
>
> The log message you are seeing is normal.
>
> Are you starting the remote server inside another
> application? I don't think this will work with
> 1.2.7.0 since by default it does not deserialize the
> value of the element you put in the cache. If you
> are
> running as a standalone server, Please upgrade to
> 1.2.7.0, just to get the latest code and other
> associated fixes and features. Let me know either
> way. We may want to make this behavior configurable
> if the remote cache used to work as an embedded
> application. I didn't think it would. Let me look
> into this.
>
> Cheers,
>
> Aaron Smuts
>
> --- Horton Simon <Si...@uk.mizuho-sc.com>
> wrote:
>
> > Hi,
> >
> >
> >
> > I was hoping that you might have seen this before
> > and may be able to
> > suggest what I might do to overcome this problem I
> > am having. I am
> > receiving a RemoteCacheFactory problem 'WARNING:
> > Error while running
> > event from Queue: PutEvent ' on the 2nd and
> > subsequent run of a client
> > program which communicates with an RMI
> > RemoteCacheFactory server. But
> > not the first run with a newly started RMI server.
> >
> >
> >
> > I have been using the 'Getting Started' and 'Basic
> > Web Example' on the
> > JCS site and have set up a client cache with
> memory,
> > disk and RMI remote
> > plug-in. I have set up two remote auxiliary remote
> > RMI servers
> > (RemoteCacheFactory) in a cluster. My test client
> > registers itself with
> > the remote server (running on the same localhost).
>
> >
> >
> >
> > RemoteUtils.createRegistry( port );
> >
> > RemoteCacheServerFactory.startup( hostName, port,
> > configFile );
> >
> >
> >
> > ...and then does the following:
> >
> >
> >
> > cache.put( key, city );
> >
> > cache.get( key );
> >
> >
> >
> > When I first start the remote server and then run
> > the client, no
> > problems reported. The object seems to be added to
> > the remote cache OK.
> >
> >
> >
> > 23-Feb-2006 16:00:10
> >
>
org.apache.jcs.auxiliary.remote.server.RemoteCacheServer
> > addCacheListener
> >
> > INFO: adding vm listener under new id = 1
> >
> > RemoteCacheServer:adding vm listener under new id
> =
> > 1 >RMI TCP
> > Connection(5)-10.110.124.209
> >
> > 23-Feb-2006 16:00:11
> > org.apache.jcs.engine.CacheEventQueue put
> >
> > INFO: Cache event queue created: CacheEventQueue
> > [listenerId=0,
> > cacheName=testCache1]
> >
> > 23-Feb-2006 16:00:21
> > org.apache.jcs.engine.CacheEventQueue$QProcessor
> > run
> >
> > INFO: QProcessor exiting for CacheEventQueue
> > [listenerId=0,
> > cacheName=testCache1]
> >
> >
> >
> >
> >
> >
> >
> > With the remote RMI server still running, I stop
> the
> > client program.
> > When I run the exact same client program again,
> the
> > remote RMI server
> > reports the error 'Error while running event from
> > Queue: PutEvent '. The
> > key and value pair being added are not null.
> >
> >
> >
> > 23-Feb-2006 16:03:59
> >
>
org.apache.jcs.auxiliary.remote.server.RemoteCacheServer
> > addCacheListener
> >
> > INFO: adding vm listener under new id = 2
> >
> > RemoteCacheServer:adding vm listener under new id
> =
> > 2 >RMI TCP
> > Connection(9)-10.110.124.209
> >
> > 23-Feb-2006 16:04:00
> > org.apache.jcs.engine.CacheEventQueue put
> >
> > INFO: Cache event queue created: CacheEventQueue
> > [listenerId=0,
> > cacheName=testCache1]
> >
> > 23-Feb-2006 16:04:00
> > org.apache.jcs.engine.CacheEventQueue put
> >
> > INFO: Cache event queue created: CacheEventQueue
> > [listenerId=1,
> > cacheName=testCache1]
>
=== message truncated ===
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error please delete it and any files transmitted with it, after notifying postmaster@uk.mizuho-sc.com
Any opinions expressed in this message may be those of the author and not necessarily those of the company. The company accepts no responsibility for the accuracy or completeness of any information contained herein. This message is not intended to create legal relations between the company and the recipient.
Recipients should please note that messages sent via the Internet may be intercepted and that caution should therefore be exercised before dispatching to the company any confidential or sensitive information.
Mizuho International plc Bracken House, One Friday Street, London EC4M 9JA. TEL. 020 72361090. Wholly owned subsidiary of Mizuho Securities Co., Ltd. Member of Mizuho Financial Group. Authorised and regulated by the Financial Services Authority. Member of the London Stock Exchange.
Registered in England No. 1203696. Registered office as above.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: RemoteCacheFactory problem 'WARNING: Error while running event from Queue:' ?
Posted by Aaron Smuts <as...@yahoo.com>.
You are right, the log messages don't have enough
information. I noticed this yesterday and I tried to
make some improvements. I'll make the specific log
statements you refer to more informative in the next
day or so.
Cheers,
Aaron Smuts
--- Horton Simon <Si...@uk.mizuho-sc.com>
wrote:
> Hi Aaron,
>
> Thanks for your quick response and detailed
> explanation. From your
> explanation I understand now that this message
> relates to the PutEvent
> failing between the remote server and the original
> dead client process.
>
> I was thinking that the following log messages
> applied to the
> communication between my new client process and the
> remote server, as
> the log messages occurred on the remote process when
> my new client
> initiated its PutEvent.
>
> 23-Feb-2006 16:04:01
>
org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent
> run
> INFO: Error while running event from Queue: PutEvent
> for key: city123
> value: null. Retrying...
> ....
> 23-Feb-2006 16:04:31
>
org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent
> run
> WARNING: Error while running event from Queue:
> PutEvent for key: city123
> value: null. Dropping Event and marking Event Queue
> as non-functional.
>
> I see now that it is not a problem.
>
> I think it would be helpful if those INFO and
> WARNING messages also
> included the listener and cacheName information e.g.
> [listenerId=0,
> cacheName=testCache1], as occurs in some of the
> other messages. This
> would make it clear that the messages were to do
> with the original dead
> client process rather than the new client process.
>
> Also, to answer your questions regarding versions
> and how I'm running
> the remote process. I am running the latest code
> 1.2.7.0 and my Remote
> RMI server is running in standalone mode.
>
> Thanks for your assistance.
> Best wishes,
> Simon
>
>
>
> -----Original Message-----
> From: Aaron Smuts [mailto:asmuts@yahoo.com]
> Sent: 24 February 2006 00:53
> To: JCS Users List
> Subject: Re: RemoteCacheFactory problem 'WARNING:
> Error while running
> event from Queue:' ?
>
> A point of clarification. The remote cache server
> can
> be embedded, but it won't necessarily do what you
> want.
>
> The remote cache server sits on top of the cache.
> It
> does not sit inside the cache as an auxiliary. When
> you cluster remote cache servers, the clusters talk
> to
> each other through the cache. Basically, the client
> is an auxiliary like any other. If it is marked as
> clustered, this means that it can have special
> behaviorial consequences. If an update comes from a
> cluster client, then the data is only sent to the
> receiver's other clients if local cluster
> consistency
> is set to true.
>
> If an item comes into the server, the local cache
> (the
> server's cache) will be updated, but not vice versa.
>
> Puts into the remote server's cache will not make it
> to the server, which is responsible for
> broadcasting.
>
> Hence, you can charge a remote server from within,
> but
> you cannot make it send through the cache. You
> could
> call send directly . . .
>
> Aaron Smuts
>
>
>
>
> --- Aaron Smuts <as...@yahoo.com> wrote:
>
> > Am I correct that all you are concerned with is
> the
> > warning?
> >
> > The remote cache is logging that the client
> > registered
> > as #1 is no longer reachable. This is the correct
> > behavior. Ideally, the client would deregister
> > itself
> > . . .
> >
> > The remote cache server has a bunch of queues.
> For
> > each region that is registered, a list of exported
> > remote cache listener objects is kept in a list.
> > When
> > an item is put into a region on the remote server,
> > the
> > remote server gets the list of listeners and then
> > updates all the listeners that are not the source
> of
> > the update. Every update contains a listener id.
> > This is assigned by the server. The listener
> needs
> > an
> > id so the remote cache knows who not to update.
> >
> > When you start the client for the first time it
> > registers with the server. If it is the first
> > client
> > to ever register it will be assigned 1. It tells
> > the
> > server what regions it is interested in. The
> remote
> > cache adds the listener to the list for each
> region
> > that the client is interested in.
> >
> > Killing the client and then restarting it results
> in
> > the client trying to register with the server
> again,
> > as it must. If this is the second registation the
> > server has received, the client will be assigned
> id
> > 2.
> > If you then put something into the cache, the
> > client
> > sends it to the server, and the server processes
> it.
> >
> > It gets the list of listeners for the region.
> This
> > list now contains two entries. (It has no way to
> > know
> > at this point that the first reference is no
> longer
> > reachable.) When it tries to send to the first
> > listener it will discover the error. It retries
> 10
> > times or so and then if the client is still not
> > reachable, it quits.
> >
> > The newly registered client should be alive and
> > healthy.
> >
> > The log message you are seeing is normal.
> >
> > Are you starting the remote server inside another
> > application? I don't think this will work with
> > 1.2.7.0 since by default it does not deserialize
> the
> > value of the element you put in the cache. If you
> > are
> > running as a standalone server, Please upgrade to
> > 1.2.7.0, just to get the latest code and other
> > associated fixes and features. Let me know either
> > way. We may want to make this behavior
> configurable
> > if the remote cache used to work as an embedded
> > application. I didn't think it would. Let me
> look
> > into this.
> >
> > Cheers,
> >
> > Aaron Smuts
> >
> > --- Horton Simon <Si...@uk.mizuho-sc.com>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > I was hoping that you might have seen this
> before
>
=== message truncated ===
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org