[OpenSIPS-Users] rabbit event not passing params 2.2
Tito Cumpen
tito at xsvoce.com
Mon Jan 25 21:40:50 CET 2016
Hey Razvan,
This is still an issue with the latest dev build. The event is entirely
empty when it is transmitted to the queue. I've tried
modparam("event_rabbitmq", "sync_mode", 1) but it does not make a
difference.
THanks,
Tito
On Mon, Jan 25, 2016 at 3:39 PM, Tito Cumpen <tito at xsvoce.com> wrote:
> Hey Razvan,
>
> This is still an issue with the latest dev build. The event is entirely
> empty when it is transmitted to the queue. I've tried
> modparam("event_rabbitmq", "sync_mode", 1) but it does not make a
> difference.
>
> THanks,
> Tito
>
> On Fri, Oct 30, 2015 at 1:20 PM, Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>> Hi, Tito!
>>
>> Apologies for getting back so late. The only addition to 2.2 was the
>> async support. Have you tried setting the sync_mode to 1
>> modparam("event_rabbitmq", "sync_mode", 1)
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 10/20/2015 08:15 PM, Tito Cumpen wrote:
>>
>> 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>
>>> 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>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>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>
>>>>> Users at lists.opensips.org>
>>>>> <mailto: <Users at lists.opensips.org>
>>>>> Users at lists.opensips.org
>>>>> <mailto: <Users at lists.opensips.org>
>>>>> 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>
>>>>> 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>
>>>>> 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
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://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/20160125/7ca5b721/attachment-0001.htm>
More information about the Users
mailing list