I'm trying to use the Memcached "touch" command to reset expiration times, but I'm consistently getting a generic error response. I've simplified things to using telnet, and I've got a pretty simple use case that demonstrates the issue.
set TestKey 0 60 9
TestValue
STORED
get TestKey
VALUE TestKey 0 9
TestValue
END
touch TestKey 300
ERROR
get TestKey
VALUE TestKey 0 9
TestValue
END
In the above snippet, I believe I am caching a value "TestValue" with the key "TestKey", and a timeout of 60 seconds. I'm then reading the value (using the key), which demonstrates it is stored correctly. I try to use touch to set the expiration to 300 seconds, but I get a response: ERROR. Finally, I get the value again (mostly to demonstrate that the entire test happened before the original value times out).
Additional details:
I also get ERROR if I try to touch a key that doesn't exist, or use the gat or gats` commands (to Get And Touch)
I've tried to make sure all my commands are formatted according to https://github.com/memcached/memcached/blob/master/doc/protocol.txt
Am I using these commands incorrectly? Does AWS ElastiCache for Memcached lack support for touch? (I can't find any documentation asserting that it does or does not)
Figured it out - We were running version 1.4.5 of the memcached engine, but apparently touch isn't fully supported (at least outside binary mode) until 1.4.24.
Upgrading to the latest engine version (1.6.12) resolved the issue.
Related
[ script:es_extended] SCRIPT ERROR: #es_extended/server/functions.lua:127: attempt to index a nil value (local 'xPlayer')
[ script:es_extended] > ref (#es_extended/server/functions.lua:127)
Please help me im triggered af Thats my Fivem Console (TxAdmin) Nothing works Esx is completly broke after a server Restart
I had a look at the source code. My best guess is that the player you are using isn't registered in the MySQL database for some reason.
I am guessing this because of the following:
The immediate cause of the error is that xPlayer is nil in server/functions.lua:127
This is due to the player object not being added to the ESX.Players table in server/main.lua:239
The info necessary to make the player object is taken from MySQL on server/main.lua:115
So the most obvious explanation would be that the user wasn't found in the database. It is also possible that the program could not connect to the database at all, but it looks like the fivem-mysql-async library would raise an error instead of continuing silently, so that is less likely (although this would need testing to discount completely).
Are there any messages in the server logs that might give you a clue as to what's going on?
Is it possible to rotate a logfile immediately in webMethods - by calling a special method or whatever. I do not want to use third-party software.
Further explanation
I need this rotation for both. The default logfile(s) (e.g. server.log) and custom logfiles.
By default webMethods logs (all components such IS, MWS, Optimize etc) rotate every 24h on midnight. You can change that interval by modifying an extended property.
For IntegrationServer 9.6 and lower it is watt.server.logRotateInterval (in milliseconds).
Please note: The watt.server.logRotateInterval parameter was removed from Integration Server after
8.2 SP2. When it was reintroduced for the following fixes, the scope of the parameter changed so that it affected only the stats.log:
IS_9.0_SP1_Core_Fix6
IS_9.5_SP1_Core_Fix3
IS_9.6_Core_Fix2
Starting with Integration Server 9.7, this server configuration parameter has been renamed watt.server.statsLogRotateInterval (in minutes instead of milliseconds), but affects only stats.log file as well.
So I think there is no way to change the log rotate interval. For compressing the old log files I think the best solution would be to write a service that does that and used that service to create a scheduled task (executed daily after midnight).
I'm using EF6 rc1 with Code First strategy, without precompiled views and the problem is:
If I compile and run the exe application it takes like 15 seconds to run the first query (that's okay, since I'm still working on the pre-generated views). But if I use Visual Studio 2013 Preview to Debug the exact same application it takes almost 2 minutes BEFORE running the first query:
Dim Context = New MyEntities()
Dim Query = From I in Context.Itens '' <--- The debug takes 2 minutes in here
Dim Item = Query.FirstOrDefault()
Is there a way to remove this extra time? Am I doing something wrong here?
Ps.: The context itself is not complicated, its just full with 200+ tables.
Edit: Found out that the problem is that during debug time the EF appears to be generating the Views ignoring the pre-generated ones.
Using the source code from EF I discovered that the property:
IQueryProvider IQueryable.Provider
{
get
{
return _provider ?? (_provider = new DbQueryProvider(
GetInternalQueryWithCheck("IQueryable.Provider").InternalContext,
GetInternalQueryWithCheck("IQueryable.Provider").ObjectQueryProvider));
}
}
is where the time is being consumed. But this is strange since it only takes time in debug. Am I missing something here?
Edit: Found more info related to the question:
Using the Process Monitor (by Sysinternals) I found out that there its the 'desenv.exe' process that is consuming tons of time. To be more specific its consuming time with an 'Thread Exit'. It repeats the Thread Exit stack 36 times. I don't know if this info is very useful, but I saved a '.cvs' with the stack, here is his body: [...] (edit: removed the '.cvs' body, I can post it again by the comments if someone really think its going to be useful, but it was confusing and too big.)
Edit: Installed VS2013 Ultimate and Entity Framework 6 RTM. Installed the Entity Framework Power Tools Beta 4 and used it to generate the Views. Nothing changed... If I run the exe it takes 20 seconds, if I 'Start' debugging it takes 120 seconds.
Edit: Created a small project to simulate the error: http://sdrv.ms/16pH9Vm
Just run the project inside the environment and directly through the .exe, click the button and compare the loading time.
This is a known performance issue in Lazy (which EF is using) when the debugger is attached. We are currently working on a fix (the current approach we are looking at is removing the use of Lazy). We hope to ship this fix in a patch release soon. You can track progress of this issue on our CodePlex site - http://entityframework.codeplex.com/workitem/1778.
More details on the coming 6.0.2 patch release that will include a fix are here - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx
I don't know if you have found the solution. But in my case, I had similar issue which wasted me close to a week after trying different suggestions. Finally, I found a solution by changing my web.config to optimizeCompilations="true" and performance improved dramatically from 15-30 seconds to about 2 seconds.
I have a daemon process that I wrote being executed by SMF. The problem is when an error occurs, I have fail code and then it will need to restart from scratch. Right now it is sending sys.exit(0) (Python), but SMF keeps throwing it in maintenance mode.
I've worked with SMF enough to know that it sometimes auto-restarts certain services (and lets others fail and have you deal with them like this). How do I classify this process as one that needs to auto-restart? Is it an SMF setting, a method of failing, what?
Manpage
Solaris uses a combination of startd/critical_failure_count and startd/critical_failure_period as described in the svc.startd manpage:
startd/critical_failure_count
startd/critical_failure_period
The critical_failure_count and critical_failure_period properties together specify the maximum number of service failures allowed in a given time interval before svc.startd transitions the service to maintenance. If the number of failures exceeds critical_failure_count in any period of critical_failure_period seconds, svc.startd will transition the service to maintenance.
Defaults in the source code
The defaults can be found in the source, the value depends on whether the service is "wait style":
if (instance_is_wait_style(inst))
critical_failure_period = RINST_WT_SVC_FAILURE_RATE_NS;
else
critical_failure_period = RINST_FAILURE_RATE_NS;
The defaults are either 5 failures/10 minutes or 5 failures/second:
#define RINST_START_TIMES 5 /* failures to consider */
#define RINST_FAILURE_RATE_NS 600000000000LL /* 1 failure/10 minutes */
#define RINST_WT_SVC_FAILURE_RATE_NS NANOSEC /* 1 failure/second */
These variables can be set in the SMF as properties:
<service_bundle type="manifest" name="npm2es">
<service name="site/npm2es" type="service" version="1">
...
<property_group name="startd" type="framework">
<propval name='critical_failure_count' type='integer' value='10'/>
<propval name='critical_failure_period' type='integer' value='30'/>
<propval name="ignore_error" type="astring" value="core,signal" />
</property_group>
...
</service>
</service_bundle>
TL;DR
After checking against the startd values, If the service is "wait style", it will be throttled to a max restart of 1/sec, until it no longer exits with a non-cfg error. If the service is not "wait style" it will be put into maintenance mode.
Presuming a normal service manifest, I would suspect that you're dropping into maintenance because SMF is restarting you "too quickly" (which is a bit arbitrarily defined). svcs -xv should tell you if that is the case. If it is, SMF is restarting you, and then you're exiting again rapidly and it's decided to give up until the problem is fixed (and you've manually svcadm clear'd it.
I'd wondered if exiting 0 (and indicating success) may cause further confusion, but it doesn't appear that it will.
I don't think Oracle Solaris allows you to tune what SMF considers "too quickly".
You have to create a service manifest. This is more complicated than not. This has example manifests and documents the manifest structure.
http://www.oracle.com/technetwork/server-storage/solaris/solaris-smf-manifest-wp-167902.pdf
As it turns out, I had two pkills in a row to make sure everything was terminated correctly. The second one, naturally, was exiting something other than 0. Changing this to include an exit 0 at the end of the script solved the problem.
I am looking for a method to detect if the gsoap web service is available.
Unfortunately when the service is offline then the client gsoap calls block
for a long time. Setting the soap.recv_timeout and the soap.send_timeout to
zero do not help.
This is a bit late, but I finally found (what I think is) a better answer by skulking through the source code (why they don't document this, I don't know):
Look for "soap.connect_timeout". When I set this to 3, it times-out after 3 seconds as expected when the web service is unavailable.
The above recv_timeout and send_timeout didn't work for me in the case of "service unavailable".
I'm pretty sure that by setting soap.recv_timeout and soap.send_timeout with 0 means NO TIMEOUT. Try set this variables with 1 (1 means 1 second).
I came here looking for a solution to the same problem and recognized the erroneous part about setting recv_timeout to 0, but I had set it to 20 and still got no timeout, so I followed the second post and used connect_timeout, which did work as I intended.