Re: [PATCH] rewrite/cleanup of dlr handling (new)
Hi what happened to this? Nisan At 12:17 AM 5/27/03 +0200, Alexander Malysh wrote: Hi all, sorry first mail has wrong diff :( attached big patch does following: 1) adds more abstraction to dlr handling 2) makes it easier to add new dlr storage types to kannel without touching a dlr-core code 3) makes dlr-core ready for coming (hopefully soon) modules API 4) makes handling/creating of dlr messages uniformly over all storage types Please look in it. Comments are very welcome... -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: a.malysh at centrium.de web: http://www.centrium.de msn: olek2002 at hotmail.com ___ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Nisan Bloch wrote: Hi what happened to this? I'm just reading it. Unfortunatly it's huge and even in unified diff almost unreadable to understand what happens. Maybe you Nisan can explain a bit?! Have you tested Alexander's code again SMSCs? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Alexander Malysh wrote: sorry first mail has wrong diff :( attached big patch does following: 1) adds more abstraction to dlr handling 2) makes it easier to add new dlr storage types to kannel without touching a dlr-core code 3) makes dlr-core ready for coming (hopefully soon) modules API 4) makes handling/creating of dlr messages uniformly over all storage types Please look in it. Comments are very welcome... ok, looks good to me. +1. will commit this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Hi,
i found a small memleak after it ...
Attached you can find corrected version of this patch.
I can say, mysql and internal where tested and works on our production systems
without any problems. libsdb is not tested yet, but should work, because i
have not changed any calls to the library itself. So please people, who use
libsdb, test it!
What happens is pretty simple ;)
1. if dlr_init calls then here storage will be initilialized return pointer to
operations struct. pls consult dlr_p.h for possible operations on the
storage.
2. If dlr_find calls then core dlr do following:
call storage get function
create new dlr message
check if this end status of message (e.g. delivered or undelivered) and then
delete the message by calling of remove storage funct. if end state not
reached then call storage update status entry funct. (its optional, that
means, if storage define this funct. it will be called otherwise not)
3. dlr_status just call storage status funct.
and so on ...
So if any questions about this code should be here, then ask!
Am Donnerstag, 19. Juni 2003 20:02 schrieb Stipe Tolj:
Nisan Bloch wrote:
Hi
what happened to this?
I'm just reading it. Unfortunatly it's huge and even in unified diff
almost unreadable to understand what happens.
Maybe you Nisan can explain a bit?!
Have you tested Alexander's code again SMSCs?
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are
--
Best regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 240
Fax: +49 (0221) 277 49 109
email: a.malysh at centrium.de
web: http://www.centrium.de
msn: olek2002 at hotmail.com
___
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
? doc/alligata/alligata.tex
? test/test_dbpool
? test/test_md5
? test/test_octstr_dump
? utils/mtbatch
Index: gw/bearerbox.c
===
RCS file: /home/cvs/gateway/gw/bearerbox.c,v
retrieving revision 1.139
diff -a -u -b -r1.139 bearerbox.c
--- gw/bearerbox.c 26 May 2003 18:37:11 - 1.139
+++ gw/bearerbox.c 17 Jun 2003 20:06:20 -
@@ -735,7 +735,7 @@
(float)counter_value(incoming_sms_counter)/t,
(float)counter_value(outgoing_sms_counter)/t,
dlr_messages(),
-octstr_get_cstr(dlr_type));
+dlr_type());
octstr_destroy(version);
ret = octstr_create(buf);
Index: gw/dlr.c
===
RCS file: /home/cvs/gateway/gw/dlr.c,v
retrieving revision 1.33
diff -a -u -b -r1.33 dlr.c
--- gw/dlr.c 27 Feb 2003 09:48:59 - 1.33
+++ gw/dlr.c 17 Jun 2003 20:06:21 -
@@ -5,6 +5,7 @@
*
* Andreas Fink [EMAIL PROTECTED], 18.08.2001
* Stipe Tolj [EMAIL PROTECTED], 22.03.2002
+ * Alexander Malysh [EMAIL PROTECTED] 2003
*
* Changes:
* 2001-12-17: [EMAIL PROTECTED]:
@@ -31,229 +32,147 @@
#include gwlib/gwlib.h
#include sms.h
#include dlr.h
+#include dlr_p.h
+
+/* Our callback functions */
+static struct dlr_storage *handles = NULL;
+
/*
-#define DLR_TRACE 1
-*/
-/*
- * We use memory based DLR
- * the structure of a delivery report waiting list entry
+ * Function to allocate a new struct dlr_entry entry
+ * and intialize it to zero
*/
+struct dlr_entry *dlr_entry_create()
+{
+struct dlr_entry *dlr;
-typedef struct dlr_wle {
- Octstr *smsc;
- Octstr *timestamp;
- Octstr *source;
- Octstr *destination;
- Octstr *service;
- Octstr *url;
- int mask;
- Octstr *boxc_id;
-} dlr_wle;
-
-/*
- * This is the global list where all messages being sent out are being kept track
- * of his list is looked up once a delivery report comes in
- */
-static List *dlr_waiting_list;
-static void dlr_destroy(dlr_wle *dlr);
-static void dlr_init_mem(void);
-#ifdef DLR_MYSQL
-static void dlr_init_mysql(Cfg* cfg);
-#endif
-#ifdef DLR_SDB
-static void dlr_init_sdb(Cfg* cfg);
-#endif
-static void dlr_shutdown_mem(void);
-static void dlr_shutdown_mysql(void);
-static dlr_wle *dlr_new(void);
+dlr = gw_malloc(sizeof(*dlr));
+gw_assert(dlr != NULL);
+
+/* set all values to NULL */
+memset(dlr, 0, sizeof(*dlr));
+
+return dlr;
+}
/*
- * At startup initialize the list, use abstraction to
- * allow to add additional dlr_init_foobar() routines here.
- *
- * Check 'dlr-storage' directive in core group to see how DLRs are
- * processed.
+ * Duplicate dlr entry
*/
-
-static void dlr_init_mem()
+struct dlr_entry *dlr_entry_duplicate(const struct
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Alexander Malysh wrote: i found a small memleak after it ... Attached you can find corrected version of this patch. I can say, mysql and internal where tested and works on our production systems without any problems. libsdb is not tested yet, but should work, because i have not changed any calls to the library itself. So please people, who use libsdb, test it! What happens is pretty simple ;) 1. if dlr_init calls then here storage will be initilialized return pointer to operations struct. pls consult dlr_p.h for possible operations on the storage. 2. If dlr_find calls then core dlr do following: call storage get function create new dlr message check if this end status of message (e.g. delivered or undelivered) and then delete the message by calling of remove storage funct. if end state not reached then call storage update status entry funct. (its optional, that means, if storage define this funct. it will be called otherwise not) 3. dlr_status just call storage status funct. and so on ... +1, commited to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] rewrite/cleanup of dlr handling (new)
Hi Andreas, Am Donnerstag, 19. Juni 2003 21:08 schrieb Andreas Fink: On Jeudi, juin 19, 2003, at 08:33 Uhr, Alexander Malysh wrote: Hi, i found a small memleak after it ... Attached you can find corrected version of this patch. I can say, mysql and internal where tested and works on our production systems without any problems. libsdb is not tested yet, but should work, because i have not changed any calls to the library itself. So please people, who use libsdb, test it! What happens is pretty simple ;) 1. if dlr_init calls then here storage will be initilialized return pointer to operations struct. pls consult dlr_p.h for possible operations on the storage. 2. If dlr_find calls then core dlr do following: call storage get function create new dlr message check if this end status of message (e.g. delivered or undelivered) and then delete the message by calling of remove storage funct. if end state not reached then call storage update status entry funct. (its optional, that means, if storage define this funct. it will be called otherwise not) 3. dlr_status just call storage status funct. I looked at the patch but I don't understand what the cleanup purpose was.. can you explain? sure... 1) make easier to add new dlr storage types to kannel without touching a dlr-core code. With old dlr handling you must to go over all storage types in order to add your's. Now u must simple implement clear defined operations for your storage type without touching any line in dlr core handling. Yet not fully true, due to lack of modules API, now you must add your new storage type (equal to SMSCConn) to dlr_init function. 2) not equal creating of dlrs for different storage types. In old dlr code we have for example in internal storage reversed source and destination addr in dlr msg but not in mysql. 3) that had grown with the time and looks bad ;) this is the same as for SMSCConn... why it was rewriten? a: in order to get things clearer and easier to handle... Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: a.malysh at centrium.de web: http://www.centrium.de msn: olek2002 at hotmail.com ___ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
