[OpenSIPS-Users] rabbit event not passing params 2.2
Tito Cumpen
tito at xsvoce.com
Tue Oct 20 19:15:10 CEST 2015
Razvan,
I went back to version: opensips 2.1.1 and found that the events are being
raised with params as expected. Meaning all is working. Any possibility it
broke sometime in 2.2-dev?
Thanks,
Tito
On Tue, Oct 13, 2015 at 5:56 PM, Tito Cumpen <tito at xsvoce.com> wrote:
> Razvan,
>
>
> Yes, There is no body in the event. The event name is as well. Would you
> like me to send you a trace ?
>
> Thanks,
> Tito
>
> On Tue, Oct 13, 2015 at 5:54 PM, Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>> Hi, Tito!
>>
>> So you do get the event, but not the parameters? Is there any body in the
>> event?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 10/13/2015 07:52 PM, Tito Cumpen wrote:
>>
>>> Răzvan,
>>>
>>> Are you referring to
>>> http://www.opensips.org/html/docs/modules/2.2.x/event_rabbitmq
>>> section 1.3?
>>> From section 2.1 it looks like the subscription syntax looks the same.
>>>
>>> Mine is as I sent it before
>>>
>>> subscribe_event("UL_AOR_INSERT",
>>> "rabbitmq:myrabbitserver/sip1dev");
>>>
>>>
>>> I think the issue lies when appending params as everything except the
>>> params are sent to the queue. I am appending params in a wrapper like
>>> this
>>>
>>>
>>> raise_event("UL_AOR_DELETE", $avp(param));
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 12, 2015 at 8:27 PM, Răzvan Crainea <razvan at opensips.org
>>> <mailto:razvan at opensips.org>> wrote:
>>>
>>> Hi, Tito!
>>>
>>> So you're saying that the exact logic works in 1.11, but not in 2.2?
>>> Starting from 2.1 the socket syntax was changed a bit, to be able to
>>> specify both the routing key and the exchange used. This was not
>>> possible in 1.11. Are you sure you are specifying both?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 10/12/2015 10:09 PM, Tito Cumpen wrote:
>>>
>>> Any idea what has broken in the current dev version ?
>>>
>>>
>>> Thanks,
>>> Tito
>>>
>>> On Thu, Oct 1, 2015 at 9:17 PM, Tito Cumpen <tito at xsvoce.com
>>> <mailto:tito at xsvoce.com>
>>> <mailto:tito at xsvoce.com <mailto:tito at xsvoce.com>>> wrote:
>>>
>>> Razvan,
>>>
>>>
>>> The connection looks fine check this output from the logs
>>>
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding int param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding int param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding int param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding int param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding int param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:destroy_avp_list: destroying list (nil)
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_raise_event_msg: found subscriber
>>> E_UL_AOR_DELETE
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:event_route:scriptroute_fetch: Fetching parameters for
>>> event
>>> E_UL_AOR_DELETE
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:event_route:scriptroute_fetch: Successfully fetched 1
>>> parameters
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:buf_init: initializing...
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> deleting this
>>> user patientdemo2.gmail and sending it to the queue for
>>> processing
>>> as patientdemo2.gmail
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_param_set: adding string param
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:evi_raise_event_msg: found subscriber
>>> MyrabbitserverIP
>>>
>>> Oct 2 01:06:34 cloud-server-06 /sbin/opensips[15024]:
>>> DBG:core:destroy_avp_list: destroying list 0x7fafc8510150
>>>
>>> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]:
>>> DBG:core:tcp_read_req: Using the global ( per process ) buff
>>>
>>> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]:
>>> DBG:core:tcp_handle_req: content-length= 0
>>>
>>> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]:
>>> DBG:core:async_tsend_stream: Async successful write from
>>> first try
>>> on 0x7fafc850e418
>>>
>>> Oct 2 01:06:39 cloud-server-06 /sbin/opensips[15042]:
>>> DBG:core:tcp_read_req: tcp_read_req end
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:probe_max_sock_buff: getsockopt: snd is initially
>>> 425984
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> INFO:core:init_sock_keepalive: TCP keepalive enabled on
>>> socket 63
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:print_ip: tcpconn_new: new tcp connection to:
>>> 50.56.XX.xXX
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:tcpconn_new: on port 56177, proto 2
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:tcpconn_add: hashes: 835, 62
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:handle_new_connect: new connection: 0x7fafc8510408
>>> 63
>>> flags: 0006
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> INFO:core:send2child: no free tcp receiver, connection
>>> passed to the
>>> least busy one (1)
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:send2child: to tcp child 0 0(15039),
>>> 0x7fafc8510408 rw 1
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:handle_io: We have received conn 0x7fafc8510408
>>> with rw 1
>>> on fd 44
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:io_watch_add: [TCP_worker] io_watch_add op (44 on
>>> 7)
>>> (0x876720, 44, 19, 0x7fafc8510408,1), fd_no=3/2111
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:tcp_read_req: Using the global ( per process ) buff
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:tcp_read: EOF on 0x7fafc8510408, FD 44
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:tcp_read_req: EOF received
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:io_watch_del: [TCP_worker] io_watch_del op on
>>> index 1 44
>>> (0x876720, 44, 1, 0x10,0x3) fd_no=4 called
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:tcpconn_release: releasing con 0x7fafc8510408,
>>> state -1,
>>> fd=-1, id=62
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15039]:
>>> DBG:core:tcpconn_release: extra_data (nil)
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:handle_tcp_worker: reader response= 7fafc8510408,
>>> -1 from 0
>>>
>>> Oct 2 01:06:48 cloud-server-06 /sbin/opensips[15053]:
>>> DBG:core:tcpconn_destroy: destroying connection
>>> 0x7fafc8510408,
>>> flags 0006
>>>
>>>
>>>
>>> Within the transmission to the queuing server I only the
>>> queue
>>> being(sip1dev) declared and nothing else.
>>>
>>>
>>> T opensips:57646 -> rabbitmqserver:5672 [AP]
>>>
>>> ........<.(....sip1dev..
>>>
>>> #
>>>
>>> T opensips:57646 -> rabbitmqserver:5672 [AP]
>>>
>>> ........<.............
>>>
>>> #
>>>
>>> T opensips:57646 -> rabbitmqserver:5672 [AP]
>>>
>>> .........
>>>
>>> #
>>>
>>> T rabbitmqserver:5672 ->opensips:57646 [A]
>>>
>>>
>>>
>>> I am using the exact same logic as far as raising events
>>> with the
>>> rabbit module goes in opensips 1.11.1-notls
>>>
>>>
>>> On Tue, Sep 29, 2015 at 4:54 AM, Răzvan Crainea
>>> <razvan at opensips.org <mailto:razvan at opensips.org>
>>> <mailto:razvan at opensips.org <mailto:razvan at opensips.org>>>
>>> wrote:
>>>
>>> So you are not seeing even the xlog() you are printing?
>>> Or
>>> you're not seeing anything on the rabbitmq server.
>>> Can you check the logs to see if there are any errors
>>> related to
>>> the rabbitmq connection?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutions
>>> www.opensips-solutions.com <http://www.opensips-solutions.com>
>>> <http://www.opensips-solutions.com>
>>>
>>> On 09/29/2015 01:10 PM, Tito Cumpen wrote:
>>>
>>> Razvan,
>>>
>>> As I am not seeing anything when transmitting to my
>>> rabbitmq
>>> server. I've ran traces locally and neither the
>>> title of the
>>> published item is sent nor the params that are
>>> being declared
>>> in the event route.
>>>
>>> Thanks,
>>> Tito
>>>
>>> On Mon, Sep 28, 2015 at 5:37 AM, Răzvan Crainea
>>> <razvan at opensips.org <mailto:razvan at opensips.org>
>>> <mailto:razvan at opensips.org <mailto:razvan at opensips.org>>>
>>>
>>> wrote:
>>>
>>> Hi, Tito!
>>>
>>> So you can detect the event, but you do not see
>>> any
>>> information attached to it?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutions
>>> www.opensips-solutions.com
>>> <http://www.opensips-solutions.com>
>>> <http://www.opensips-solutions.com>
>>>
>>> On 09/22/2015 11:09 PM, Tito Cumpen wrote:
>>>
>>> Group,
>>>
>>>
>>> I am noticing issues with 2.2 dev in
>>> reference to sending
>>> params when raising an event route. I am
>>> not seeing
>>> params being sent nor the name of the event
>>> when sending
>>> event to a rabbitmq server declared in the
>>> startup route.
>>>
>>> Here is out I have implemented and wrapped
>>> the event.
>>>
>>>
>>> event_route[E_UL_AOR_DELETE] {
>>>
>>> fetch_event_params("aor=$avp(aor)");
>>>
>>>
>>> $avp(param) = "myip";
>>>
>>> $avp(param) = $avp(aor);
>>>
>>>
>>> xlog("deleting this user $avp(aor) and
>>> sending it to the
>>> queue for processing as $avp(param)\n");
>>>
>>>
>>> raise_event("UL_AOR_DELETE",
>>> $avp(param));
>>>
>>>
>>> }
>>>
>>>
>>> startup_route {
>>>
>>>
>>> subscribe_event("UL_AOR_DELETE",
>>> "rabbitmq:rabbitmq/myqueue");
>>>
>>> }
>>>
>>> Please advise if logs or a trace are
>>> necessary.
>>>
>>>
>>> Thanks,
>>>
>>> Tito
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>
>>> <mailto:Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> <mailto:Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> <mailto:Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> <mailto:Users at lists.opensips.org <mailto:
>>> Users at lists.opensips.org>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151020/ac147942/attachment-0001.htm>
More information about the Users
mailing list