CacheBox service and agents are stale, having trouble re-initializing
Kerr
integrated management app and all of the options available to me. On
my dev server running CF9, I established a couple of application
scoped agents to store content. The agents are using default in-
memory storage with an LRU:2000 eviction policy.
Over the weekend, both my application and cache set dormant, or in
other words for longer than the maximum timeout for application
variables, which was set at two days in CF Admin. I came back to the
office this morning and fired up the CacheBox management application
to find that my cache agents appear to be stuck, with the newest
content being three days old. Adding new content to my caches using
agent.store() does return a status of "0", but when I examine my
caches using the management app, the newly stored items are not there.
When I attempt to reset the agents via the management application,
nothing happens. I've also tried re-initializing the agents from my
CF code, even changing to LRU:200 to see if the agents are actually
being reset. I double checked, and the scheduled task for the service
runs with a result of "Monitoring Complete". Finally, I tried doing
a StructDelete(server,"cachebox") to ensure the service itself wasn't
the issue. Further, the home page of the management app contains very
stale information.
Nothing I've tried seems to be working. I'd like not to have to
bounce ColdFusion as I need to know how to fix this kind of issue
should it ever occur in production. Granted, in a production scenario
the applications containing the caches would not likely go dormant for
such a long, but I view bouncing CF as a last resort. Any ideas?
Kerr
my agents one time during application set-up, and storing them as
objects within my application scope.
Jeff S.
requested context doesn't match the actual context.
Do you notice "additional" entries in your agents settings file?
/cachebox/settings/agents.xml.cfm
For instance, we have a clustered environment, so for a few agents,
our requested scope is cluster. For the other agents, we use the
application scope.
If we're in our local dev environment (not clustered), and request the
clustered scope which isn't available, then the agents are set to
server by default (which caused us a few issues). We worked these out
by making sure our config files are correct per environment.
Also, on every request, we have some code similar to:
<cfif not StructKeyExists(application, "MyAgents")>
<!--- Create all agents --->
<!--- Inside a cflock: <cfset application.MyAgents = blahBlah() /> ---
>
</cfif>
This may help you out with the issue you're seeing.
Kerr
still becoming familiar with the internals, but I presume that my
initializing an agent would then create / make changes to
agents.xml.cfm. I don't see any configuration issues that should
prevent the creation or modification of this file, though I suspect
its absence may be the issue. That said, I'm unsure of what to do at
this point to remedy that. I'll dig a bit in the source to see if I
can find something.
I have almost identical code written for initializing my agents,
locking and all. The only operative difference is I've added an
optional URL based reset indicator to my surrounding <cfif>.
Jeff S.
to only be written after making changes using the CacheBox admin (and
may only be used/read when restarting cf).
We have that file checked into SVN though (so it always exists).
We're still in the testing phase (haven't went to production yet). If
you notice anything else, please share, as I'd be interested in seeing
if we can reproduce issues you notice.
Kerr
At this point I'm hoping Isaac picks up on this and dispenses some
nuggets of wisdom. ;)
s. isaac dealey
> still becoming familiar with the internals, but I presume that my
> initializing an agent would then create / make changes to
> agents.xml.cfm. I don't see any configuration issues that should
> prevent the creation or modification of this file, though I suspect
> its absence may be the issue. That said, I'm unsure of what to do at
> this point to remedy that. I'll dig a bit in the source to see if I
> can find something.
Oddly enough, no... The agents.xml file is only created if you manually
configure an agent through the admin - otherwise, the service uses
whatever your application offered up as the settings for the agent, in
combination with service defaults. So it only needs XML if you choose to
manually override those defaults, which is why you don't have one. So
you're fine in that respect.
ike
--
s. isaac dealey :: AutLabs
Creating meaningful employment for people with Autism
http://www.autlabs.com
ph: 817.385.0301
http://onTap.riaforge.org/blog
s. isaac dealey
>
> /cachebox/settings/agents.xml.cfm
>
> For instance, we have a clustered environment, so for a few agents,
> our requested scope is cluster. For the other agents, we use the
> application scope.
>
> If we're in our local dev environment (not clustered), and request the
> clustered scope which isn't available, then the agents are set to
> server by default (which caused us a few issues). We worked these out
> by making sure our config files are correct per environment.
That's a bit of an interesting subject that I just realized is not
really explained in the documentation for cachebox. The extra entries
for the agent in the agents XML file occur because the system manages
configuration based on both the name of the agent and its context.
So for example, if your requested context is "cluster", but you don't
actually have a cluster configured in the environment (staging or dev
servers for example), it will revert to the "server" context. So if you
then manually configure the agent settings once it's dropped down to
server, the system handles and stores those configs separately from the
configs it stores when the requested cluster context is available.
That way if you need to have different environments that might have
slightly different caching needs due to context availability, you
shouldn't run into issues when you transfer the configs between those
environments for say a push from staging to production, etc. Since each
context has its own config for the agent, it just uses the config that
applies in the current environment and ignores any others.
Kerr
pull a bit of hair out with this strange issue though. I've attempted
renaming both my application name and agent names to new names, and
they don't show up in the management application. I also tried
changing the context of my agents to Server, again to no avail. I'm
confident that bouncing CF will clear the issue, though I'm reticent
to do so for aforementioned reasons, as well as the fact that the
issue may be difficult to replicate. Have you heard of anything like
what I explain?
> Creating meaningful employment for people with Autismhttp://www.autlabs.com
> ph: 817.385.0301
>
> http://onTap.riaforge.org/blog
Kerr
agents and their scope (now Server), and then re-initializing them, an
error was thrown on line 48 of agentmanager.cfc: "The requested agent
is not registered." I guess that makes sense since I have not been
seeing any recent cache entries at all in the management application.
It seems as if the management application simply checked out.
Jeff S.
I think you made it clear in your documentation :)
It was just something we ran into when sharing configs between
developers (and environments). It ended up being pretty easy to sort
out...
> Creating meaningful employment for people with Autismhttp://www.autlabs.com
> ph: 817.385.0301
>
> http://onTap.riaforge.org/blog
Jeff S.
I just uploaded a file called CompareContexts.cfm to the files section
of this group.
The error you are speaking about is the same error we were running
into when sharing configs (and requesting "cluster" context when the
agent ended up being created with the "server" context).
Anyways, this is a task that I've been considering setting up when we
go live. If for any reason the applied context doesn't match the
requested context, I'd like an email, and some type of "init" action
to occur.
I'm not really sure we'll need this task though (now that we seem to
have narrowed down the problem to sharing/config problems)...
s. isaac dealey
>
> I think you made it clear in your documentation :)
>
> It was just something we ran into when sharing configs between
> developers (and environments). It ended up being pretty easy to sort
> out...
Oh okay... well I don't think it's specifically mentioned that the
agents.xml file is only created if you manually configure an agent. :)
Thanks for the clarification though, I wasn't actually looking at the
doc when I wrote that, I was just thinking about what I'd written.
s. isaac dealey
> pull a bit of hair out with this strange issue though. I've attempted
> renaming both my application name and agent names to new names, and
> they don't show up in the management application. I also tried
> changing the context of my agents to Server, again to no avail. I'm
> confident that bouncing CF will clear the issue, though I'm reticent
> to do so for aforementioned reasons, as well as the fact that the
> issue may be difficult to replicate. Have you heard of anything like
> what I explain?
No unfortunately it's not an issue I've seen before, so without
replicating it here (which I haven't had time to attempt yet), I'd be
grasping as well. Feel free to email me a zip copy of your cachebox
installation + configs though, along with maybe the code where you're
creating your agents in your app, and I'll glance over them.
Off the top of my head the only thing that springs to mind sounds so
unlikely I'm hesitant to even suggest it, but what are your caching
settings in the CF Admin? In particular there's a checkbox in the admin
for servers where the code won't change for the lifetime of the server
and if that's checked, I'd try unchecking it. But as I said, it sounds
like such a stretch to me that it just sounds goofy to suggest that
might be causing the problem.
s. isaac dealey
> into when sharing configs (and requesting "cluster" context when the
> agent ended up being created with the "server" context).
>
>
> I'm not really sure we'll need this task though (now that we seem to
> have narrowed down the problem to sharing/config problems)...
Hmmm... speaking of which, very important, never edit the XML files by
hand -- they have to be edited through the cachebox admin. :)
But if folks are running into these kinds of issues with any regularity,
we probably should see about finding some way to clarify the issue and
simplify the fix in the admin interface. :)
Kerr
server and the agentQuery returned zero records. I haven't personally
gone the cluster route for storage as I'm not in that kind of
environment, so perhaps the issue being solved in your scenario is
different than mine. At this point I think I'm going to go ahead and
bounce CF and see what happens over the course of the next few days.
Isaac - This particular server is my team's dev server, and as such we
have all caching settings within CF Admin disabled. Per the above,
and given the fact that the CacheBox service just seems to be dead,
I'm going to bounce CF and see what happens. There are about 20
developers working on this server, and it's possible that another
developer has done something with the shared memory scope that is
causing issues.
Thanks to both of you for your prompt and informative replies! I'll
check back here soon and let you guys know if I see this happen again.
Kerr
after restarting CF services on my dev box. Ike, per your prior
message I have forwarded you a zip file of my CacheBox installation,
as well as a copy of the code where I instantiate the agents. It's
pretty straightforward stuff, so I'm not sure what I could be doing
differently.
Kerr
have been running the CacheBox service since then (approx. 3 days). A
half hour ago, the graphs on the CacheBox management application's
home page quit updating. The scheduled task is still running, but
CacheBox Service agains seems to have just died. I did a server dump,
looking for "server.cachebox", and it is in fact there. I'm not sure
what troubleshooting steps to take next, though at this point it seems
to be a recurrent issue. The only additional detail I know at this
point is that the ColdFusion service has been running for just over
three days. I'm not sure what steps to take next unfortunately.
Ike, per a prior message of yours, I have zipped and forwarded to you
my cachebox installation and the application code used to instantiate
the agents. If you don't mind, take a look at your convenience and
let me know if you spot anything that looks odd.
Thank you, and have a great weekend!
Kerr
On Mar 23, 6:43 am, Kerr <hayl...@gmail.com> wrote:
Kerr
ColdFusion on our dev box to Cumulative Hot Fix 1 (
http://kb2.adobe.com/cps/825/cpsid_82536.html ) and whatever the
problem was with my cache agents, it now appears to be fixed. I've
made absolutely no changes to the core CacheBox code, so good news
there! I'll post back if I experience this issue again.
--
Subscription settings: http://groups.google.com/group/cfcachebox/subscribe?hl=en