Re: svn commit: r1768245 - /httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

2016-11-18 Thread Christophe JAILLET

Le 05/11/2016 à 17:47, j...@apache.org a écrit :

Author: jim
Date: Sat Nov  5 16:47:43 2016
New Revision: 1768245

URL: http://svn.apache.org/viewvc?rev=1768245&view=rev
Log:
heh... bring memcache up to redis :)
mod_status info

Modified:
 httpd/httpd/trunk/modules/cache/mod_socache_memcache.c

Modified: httpd/httpd/trunk/modules/cache/mod_socache_memcache.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_socache_memcache.c?rev=1768245&r1=1768244&r2=1768245&view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_socache_memcache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_socache_memcache.c Sat Nov  5 16:47:43 
2016
@@ -17,6 +17,7 @@
  
  #include "httpd.h"

  #include "http_config.h"
+#include "http_protocol.h"
  
  #include "apr.h"

  #include "apu_version.h"
@@ -33,6 +34,8 @@
  #include "ap_mpm.h"
  #include "http_log.h"
  #include "apr_memcache.h"
+#include "apr_strings.h"
+#include "mod_status.h"
  
  /* The underlying apr_memcache system is thread safe.. */

  #define MC_KEY_LEN 254
@@ -293,7 +296,58 @@ static apr_status_t socache_mc_remove(ap
  
  static void socache_mc_status(ap_socache_instance_t *ctx, request_rec *r, int flags)

  {
-/* TODO: Make a mod_status handler. meh. */
+apr_memcache_t *rc = ctx->mc;
+int i;
+
+for (i = 0; i < rc->ntotal; i++) {
+apr_memcache_server_t *ms;
+apr_memcache_stats_t *stats;
+apr_status_t rv;
+char *br = (!(flags & AP_STATUS_SHORT) ? "" : "");

Is there reaaly a need for the 'br'...

+
+ms = rc->live_servers[i];
+
+ap_rprintf(r, "Memcached server: %s:%d [%s]%s\n", ms->host, 
(int)ms->port,
+(ms->status == APR_MC_SERVER_LIVE) ? "Up" : "Down",
+br);

... which could be inlined here and...

+rv = apr_memcache_stats(ms, r->pool, &stats);
+if (rv != APR_SUCCESS)
+continue;
+if (!(flags & AP_STATUS_SHORT)) {
+ap_rprintf(r, "Version: %s [%u bits], PID: %u, Uptime: %u 
hrs \n",
+stats->version , stats->pointer_size, stats->pid, 
stats->uptime/3600);
+ap_rprintf(r, "Clients:: Structures: %u, Total: %u, Current: 
%u \n",
+stats->connection_structures, stats->total_connections, 
stats->curr_connections);
+ap_rprintf(r, "Storage:: Total Items: %u, Current Items: %u, Bytes: 
%lu \n",
+stats->total_items, stats->curr_items, stats->bytes);
+ap_rprintf(r, "CPU:: System: %u, User: %u 
\n",
+(unsigned)stats->rusage_system, 
(unsigned)stats->rusage_user );
+ap_rprintf(r, "Cache:: Gets: %u, Sets: %u, Hits: %u, Misses: 
%u \n",
+stats->cmd_get, stats->cmd_set, stats->get_hits, 
stats->get_misses);
+ap_rprintf(r, "Net:: Input bytes: %lu, Output bytes: %lu 
\n",
+stats->bytes_read, stats->bytes_written);
+ap_rprintf(r, "Misc:: Evictions: %lu, MaxMem: %u, Threads: 
%u \n",
+stats->evictions, stats->limit_maxbytes, stats->threads);
+ap_rputs("\n", r);
+}
+else {
+ap_rprintf(r, "Version: %s [%u bits], PID: %u, Uptime: %u hrs 
%s\n",
+stats->version , stats->pointer_size, stats->pid, 
stats->uptime/3600, br);
+ap_rprintf(r, "Clients:: Structures: %d, Total: %d, Current: %u 
%s\n",
+stats->connection_structures, stats->total_connections, 
stats->curr_connections, br);
+ap_rprintf(r, "Storage:: Total Items: %u, Current Items: %u, Bytes: %lu 
%s\n",
+stats->total_items, stats->curr_items, stats->bytes, br);
+ap_rprintf(r, "CPU:: System: %u, User: %u %s\n",
+(unsigned)stats->rusage_system, 
(unsigned)stats->rusage_user , br);
+ap_rprintf(r, "Cache:: Gets: %u, Sets: %u, Hits: %u, Misses: %u 
%s\n",
+stats->cmd_get, stats->cmd_set, stats->get_hits, 
stats->get_misses, br);
+ap_rprintf(r, "Net:: Input bytes: %lu, Output bytes: %lu %s\n",
+stats->bytes_read, stats->bytes_written, br);
+ap_rprintf(r, "Misc:: Evictions: %lu, MaxMem: %u, Threads: %u 
%s\n",
+stats->evictions, stats->limit_maxbytes, stats->threads, 
br);

... which is mostly used to append nothing here ?


+}
+}
+
  }
  
  static apr_status_t socache_mc_iterate(ap_socache_instance_t *instance,








Re: svn commit: r1769677 - /httpd/httpd/branches/2.4.x/STATUS

2016-11-18 Thread William A Rowe Jr
On Mon, Nov 14, 2016 at 8:07 PM, William A Rowe Jr 
wrote:

> On Mon, Nov 14, 2016 at 1:02 PM,  wrote:
>
>> Author: wrowe
>> Date: Mon Nov 14 19:02:29 2016
>> New Revision: 1769677
>>
>> URL: http://svn.apache.org/viewvc?rev=1769677&view=rev
>> Log:
>> Promote one patch, propose one historically tangled patch
>>
>> +  *) Propose default strict RFC7230 behavior, and HttpProtocolOptions
>> directive
>> + to relax or further constrain some behaviors.
>> + trunk patches: too numerous to list, see
>> +   svn log --stop-on-copy http://svn.apache.org/repos/as
>> f/httpd/httpd/branches/2.4.x-merge-http-strict/
>> + 2.4.x patch: see
>> +   svn diff -r1767912:HEAD http://svn.apache.org/repos/as
>> f/httpd/httpd/branches/2.4.x-merge-http-strict/
>> + +1: wrowe
>>
>
> Patch attached. There were some incremental comments to the merge branch
> that may or may not still apply, please reiterate your point.
>

The patch suggested by rpluem has been integrated, a small broken diff
to the  httpd.h is corrected. So I'm attaching a refreshed net diff.



> I'm aware of one possible failing of this backport which I would like to
> fix on
> 2.4 after the backport is in... compilers may complain of assignment of the
> r->protocol to a const char*, we may need apr_pstrcpy's scattered about.
>

In practice I've found no error here, not even a warning in maintainer mode.



> Thanks to everyone who has contributed to this work on trunk/ or simply
> providing feedback on dev@.
>
> The earliest i will commit this backport is noon-ish Tuesday from Spain.
>

Looking forward to some reviewers of this net patch so we can move forward.


httpd-2.4-merge-http-strict.patch
Description: Binary data


Re: Hackathon tomorrow?

2016-11-18 Thread Nick Kew
On Thu, 2016-11-17 at 09:40 -0500, Rich Bowen wrote:
> If you're around Apachecon Tomorrow please consider dropping by the
> hackathon area on floor -2 to work on the items in
> https://public.etherpad-mozilla.org/p/aceu-2016-hackathon
> 
> Thanks. 

I'm here now, and looked around both here and in the area
upstairs several times this morning.  No sign of any
coordinated hacking, except the inevitable infra huddle.

Am I just missing some (other?) hackathon area where you're
all gathered?

-- 
Nick Kew