Re: Aw: Re: [RFC] Wireshark dissector for SPOP

[Frederic Lecaille]

Hi Danny,

On 03/13/2018 09:05 PM, my.card@web.de wrote:
Thanks for your hint, but I couldn't find a good heuristic to 
distinguish SPOP from TCP. I think, that the current implementation is 
usable enough for development purposes. Feel free to enhance it. :-)


Ok.

Do not hesitate to send a patch for your dissector to haproxy mailing 
list. It could be put in contrib/wireshark-dissectors/spop directory.


Regards.

Re: cppcheck finding

[Илья Шипицин]

any action on that ?

2018-03-08 22:29 GMT+05:00 Olivier Houchard :

> Hi,
>
> On Thu, Mar 08, 2018 at 05:44:31PM +0100, Willy Tarreau wrote:
> > Hi,
> >
> > On Wed, Mar 07, 2018 at 03:26:25PM +0500,  ??? wrote:
> > > Hello,
> > >
> > > [src/proto_uxst.c:160]: (warning) Redundant assignment of
> > > 'xfer_sock->next->prev' to itself.
> > >
> > > is it in purpose ?
> >
> > I suspect it's a mistake and that it was meant to be xfer_sock->prev
> instead.
> > CCing Olivier to double-check.
> >
>
> Oops, you're right, good catch !
> The attached patch should fix it.
>
> Regards,
>
> Olivier
>

New 1.8 release ?

[Olivier Doucet]

Hello all,

I can see several fixes in 1.8 trunk about 100% CPU usage and some other
bugs.
Last release was more than a month ago. Is there a new release expected
soon ? I'm about to start using 1.8 on some production boxes and wanted to
start on a fresh new release with all known bugs fixed :)

Thank you !

Olivier

article update

[John Hawthorne]

Hello there

Your page 
http://feedjunkie.com/item/26597761/Facebook%20explores%20whether%20social%20media%20is%20good%20for%20demo
 has some good references to mass media so I wanted to get in touch with you. 
I've recently written an article about impact of mass media
and was wondering if you thought my article could help out on your page.

You can read all the information right here:



https://www.mastersincommunications.org/mass-media-good-bad-family/
It would be great to know your opinion on the article. And if you find it 
useful please consider linking to it from that page of yours, or perhaps in 
your future writing. Also if you prefer you may republish the article. How does 
this sound to you?.

Thank you very much,

John.

Re: segfault in haproxy=1.8.4

[Максим Куприянов]

Hi, Christopher!

Thank you very much for the patch. I'll apply it to my canary host today
but it will take a week or even more to assure that no crashes occur.
Anyway I'll write you back.

2018-03-14 23:56 GMT+03:00 Christopher Faulet :

> Le 07/03/2018 à 09:58, Christopher Faulet a écrit :
>
>> I found thread-safety bugs about the management of pending connections.
>> It is totally fucked up :) It needs to be entirely reworked. I'm on it.
>> I hope to propose a patch this afternoon.
>>
>
> Hi,
>
> Sorry for the lag. This issue was definitely harder to fix that I thought
> so at first glance. Here is a proposal to fix queues management. Could you
> check if it fixes your bug please ?
>
> --
> Christopher Faulet
>

RE: APhA Attendees Email List 2018

[Jennifer Gannon]

 

 

Hi,

 

I hope you’re doing well.

 

I was wondering if you had a chance to review my previous email that I sent
to you.

 

Kindly let me know your interest so that I can get back to you with counts
and pricing available.

 

Best Regards,

Jennifer

 

From: Jennifer Ganon [mailto:jennifer.ga...@globaletradsz.com] 
Sent: 01 February 2018 15:48
To: 'haproxy@formilux.org'
Subject: APhA Attendees Email List 2018

 

Hi,

 

Would you be interested in acquiring American Pharmacists Association
Attendees Email List 2018 for pre-show marketing campaign, Networking and
various Marketing initiatives.

 

List includes E-mail address and Contact number on an excel spread sheet.

 

Visitors Interest :

 

Ø  Pharmacy professionals

Ø  Practicing pharmacists

Ø  Pharmaceutical scientists

Ø  Student pharmacists

Ø  Pharmacy technicians

 

If you are interested please let me know so that I can get back to you with
the number of counts we have and pricing for the same.

 

Regards,

Jennifer Ganon

Business Development Executive

 

If you do not wish to receive future emails from us, please reply as 'Leave
out'

Re: cppcheck finding

[Willy Tarreau]

Hi,

On Wed, Mar 14, 2018 at 06:09:26PM +0500,  ??? wrote:
> any action on that ?

It was merged :
  - ec9516a6 in mainline
  - 60238357 in 1.8 branch

Thanks,
Willy

MODEX -Potential Clients

[Joanne Chandler]

Hi,

 

Would you be interested in Logistics, Manufacturing, Supply Chain,
Procurement, Material Handling and Distribution?

 

We are a global B2B database provider, we have database for US, UK, Canada,
Australia, APAC, EMEA Rest of the World.

 

Ø  Material Handling Equipment and Systems

Ø  Packaging, Containers, and Shipping 

Ø  Inventory Management and Controlling 

Ø  Dock and Warehouse Equipment and Supplies

Ø  Automatic Identification Equipment

Ø  Supply Chain Management.

 

Lists include:- Company Name, Contact Name, Title, Address, Web Site, Phone
Number, Fax Number, Verified E-mail Address, Employee Size, Revenue size,
SIC Code, Industry Type, NAICS Code, E-mail verification result.

 

If you are interested in our services, please provide us your target
requirements in the below given parameters.

 

Target market:- 

Target Geography:- __

Target Job Titles:-

 

Please share your valuable requirement in which industry you are looking for
and I will revert back to you with some samples for your review.

 

Note: - If you’re interested in any other specific Industry database?  so
that I can get back to you with counts, pricing and other relevant
information

 

Looking forward to hear from you soon .

 

Best Regards,

Joanne Chandler

Marketing Executive

 

Note: If you are not the right person please forward this email to right
person, I appreciate your time PS: We help you connect with your best
prospects and build relationships.

 

Note: You were specifically sent this email based upon your company profile.
If for some reason this was sent in error or you wish not to receive any
further messages from us please reply with subject line as "Exclude" and you
will be excluded from all future mailings.

 

Docker EE Plugins

[Norman Branitsky]

In this document:
https://blog.docker.com/2018/03/enhanced-layer-7-routing-swarm-docker-enterprise-edition-beta/?mkt_tok=eyJpIjoiTnprNE5XTTBORFk0Tm1ReCIsInQiOiJ2bTgxWGdpczRcL0Q3Z1wvNmZVdTBrWDhMbFZzUjhSMVExeUpLZUxcL3p5dVkwanJVUTlTejRIRHIwODQzZUZ0Z1RGeFFCaklhK3VPbXBTaTQ5Q2JpUTBSSDZYWktBWU53eUhiNkpQa1AyQ3hTMlJicXRIK1N5M1Y1VHRxZ0VwS0NCMiJ9
Docker EE announces the following:
Proxy Extensions

The new Interlock architecture in Docker EE includes a pluggable extension 
service that can connect to different load-balancing proxies. As part of 
Docker's "batteries included" strategy, the service comes with a supported 
NGINX proxy today and other proxy solutions will be pluggable into the 
architecture in the future. The pluggable framework allows you to use industry 
standard solutions while still having the simplicity of configuring them using 
standard Docker rolling updates.

What would it take to get a plugin for HAProxy?

Re: segfault in haproxy=1.8.4

[Christopher Faulet]

Le 07/03/2018 à 09:58, Christopher Faulet a écrit :

I found thread-safety bugs about the management of pending connections.
It is totally fucked up :) It needs to be entirely reworked. I'm on it.
I hope to propose a patch this afternoon.


Hi,

Sorry for the lag. This issue was definitely harder to fix that I 
thought so at first glance. Here is a proposal to fix queues management. 
Could you check if it fixes your bug please ?


--
Christopher Faulet
>From 32926ada6a00c11980182d582a521d3833e36f23 Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Wed, 14 Mar 2018 16:18:06 +0100
Subject: [PATCH] BUG/MAJOR: thread/queue: Fix thread-safety issues on the
 queues management

The management of the servers and the proxies queues was not thread-safe at
all. First, the accesses to ->pend_pos were not protected. So it was
possible to release it on a thread (for instance because the stream is released)
and to use it in same time on another one (because we redispatch pending
connections for a server). Then, the accesses to stream's information (flags and
target) from anywhere is forbidden. To be safe, The stream's state must always
be updated in the context of process_stream.

So to fix these issues, the queue module has been refactored. A lock has been
added in the pendconn structure. And now, when we try to dequeue a pending
connection, we start by unlinking it from the server/proxy queue and we wake up
the stream. Then, it is the stream reponsibility to really dequeue it (or
release it). This way, we are sure that only the stream can create and release
its  field.

However, be careful. This new implementation should be thread-safe
(hopefully...). But it is not optimal and in some situations, it could be really
slower in multi-threaded mode than in single-threaded one. The problem is that,
when we try to dequeue pending connections, we process it from the older one to
the newer one independently to the thread's affinity. So we need to wait the
other threads' wakeup to really process them. If threads are blocked in the
poller, this will add a significant latency. This problem happens when maxconn
values are very low.

This patch must be backported in 1.8.
---
 include/common/hathreads.h |   2 +
 include/proto/queue.h  |   1 +
 include/types/queue.h  |   9 +-
 include/types/stream.h |   2 +-
 src/proto_http.c   |   2 -
 src/queue.c| 283 +++--
 src/stream.c   |   3 +-
 7 files changed, 180 insertions(+), 122 deletions(-)

diff --git a/include/common/hathreads.h b/include/common/hathreads.h
index 3da6dba4..19299db7 100644
--- a/include/common/hathreads.h
+++ b/include/common/hathreads.h
@@ -240,6 +240,7 @@ enum lock_label {
 	PIPES_LOCK,
 	START_LOCK,
 	TLSKEYS_REF_LOCK,
+	PENDCONN_LOCK,
 	LOCK_LABELS
 };
 struct lock_stat {
@@ -360,6 +361,7 @@ static inline const char *lock_label(enum lock_label label)
 	case PIPES_LOCK:   return "PIPES";
 	case START_LOCK:   return "START";
 	case TLSKEYS_REF_LOCK: return "TLSKEYS_REF";
+	case PENDCONN_LOCK:return "PENDCONN";
 	case LOCK_LABELS:  break; /* keep compiler happy */
 	};
 	/* only way to come here is consecutive to an internal bug */
diff --git a/include/proto/queue.h b/include/proto/queue.h
index f66d809f..2d4773a0 100644
--- a/include/proto/queue.h
+++ b/include/proto/queue.h
@@ -38,6 +38,7 @@ extern struct pool_head *pool_head_pendconn;
 
 int init_pendconn();
 struct pendconn *pendconn_add(struct stream *strm);
+int pendconn_dequeue(struct stream *strm);
 void pendconn_free(struct pendconn *p);
 void process_srv_queue(struct server *s);
 unsigned int srv_dynamic_maxconn(const struct server *s);
diff --git a/include/types/queue.h b/include/types/queue.h
index 4b354514..3e7d5a12 100644
--- a/include/types/queue.h
+++ b/include/types/queue.h
@@ -24,15 +24,18 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
 struct stream;
 
 struct pendconn {
-	struct list list;		/* chaining ... */
-	struct stream *strm;		/* the stream waiting for a connection */
-	struct server *srv;		/* the server we are waiting for */
+	intstrm_flags; /* stream flags */
+	struct stream *strm;
+	struct server *srv;/* the server we are waiting for, may be NULL */
+	struct listlist;   /* next pendconn */
+	__decl_hathreads(HA_SPINLOCK_T lock);
 };
 
 #endif /* _TYPES_QUEUE_H */
diff --git a/include/types/stream.h b/include/types/stream.h
index 227b0ffb..0dbc79f4 100644
--- a/include/types/stream.h
+++ b/include/types/stream.h
@@ -124,7 +124,7 @@ struct stream {
 	struct session *sess;   /* the session this stream is attached to */
 
 	struct server *srv_conn;/* stream already has a slot on a server and is not in queue */
-	struct pendconn *pend_pos;  /* if not NULL, points to the position in the pending queue */
+	struct pendconn *pend_pos;  /* if not NULL, points to the pending position in the