Error when adding new value to LLIST


#1

Edit

I figured that adding a dummy entry first, using the aql, would mask the Create Specification Error. I guess that problem is related to the fact that it’s the very first entry being added. Maybe the Ruby client is sending a bad policy?

Anyway, doing so I managed to add values using the llist.add interface, and I realised there is a 30-character limit to the “key” entry. Key’s greater than 30 will raise 1433:LDT-Key Field Not Found..

Back to the original bug… It feels too hack-y having to add a dummy entry with aql, instead of relying on the client. Does it feels like a client bug? Should I create an issue at the client repository? I will wait a bit, maybe this bug is related to the Aerospike server instead, though I don’t think so.

#####

Hi,

When I try to add a new value to a LLIST, I get /opt/aerospike/sys/udf/lua/ldt/lib_llist.lua:5297: 1442:LDT-Input Create Specification Error

The funny part is that sometimes this errors happens, sometimes it doesn’t. For example:

Using my app I try to add the (first) value as follow:

{
    "key": "pay4u2cn7Re5", 
    "topic": "user.login", 
    "user_id": 1, 
    "ts": 1433601869, 
    "websocket_id": "1f1446b5-e5be-4518-a61c-9ded560439c9"
}

and I get the aforementioned error.

Then I manually change the data to (removed websocket_id)

{
    "key": "pay4u2cn7Re5", 
    "topic": "user.login", 
    "user_id": 1, 
    "ts": 1433601869, 
}

and the value gets inserted to the LLIST.

Then, I try again with a very similar request: (just added 2 to the key)

{
    "key": "pay4u2cn7Re52", 
    "topic": "user.login", 
    "user_id": 1, 
    "ts": 1433601869, 
    "websocket_id": "1f1446b5-e5be-4518-a61c-9ded560439c9"
}

and I managed to insert this value.

However, when I try a new value, like

{
    "key": "cqFPAb1GSXfQ", 
    "topic": "user.login", 
    "user_id": 1, 
    "ts": 1433602885, 
    "websocket_id": "c857eb82-5b43-4558-8172-b5c77228b6dc"
}

it fails.

I’m using the Ruby client and the code is as follows:

  def llist_add(key, bin, name, value)

    llist = @client.get_large_list(key, bin)

    begin
      llist.add({key: name}.merge(value))
    rescue Aerospike::Exceptions::Aerospike => boom
      puts boom
      return boom
    end

  end

  def llist_find(key, bin, name)
    llist = @client.get_large_list(key, bin)
    llist.find({key: name})
  end

(key is the mapped object with namespace:set:record, bin is just the bin name (string), name is the llist key and value is it’s value)

Any idea what this might be? Or how I could debug this issue?

Peeking into the lib_llist.lua code, it references createSpec, which is furter referenced as user module.

Maybe this thread has something to do with my problem. Maybe I need to manually add a createModule.lua (why isn’t the default working?).

However, I got an error when trying to register the module posted on that thread, and to be honest I have no idea how to work on a UDF/Lua module and how to change whatever I have to to solve this problem.

Any help is appreciated. Thanks.


#2

Renatomassaro,

What is the server version

/usr/bin/asd --version

or

rpm -qa |grep aerospike

– R


#3

@renatomassaro,

Thank you for posting about LDTs in our forum. Please see the LDT Feature Guide for current LDT recommendations and best practices.


#4

@renatomassaro,

Effective immediately, we will no longer actively support the LDT feature and will eventually remove the API. The exact deprecation and removal timeline will depend on customer and community requirements. Instead of LDTs, we advise that you use our newer List and SortedMap APIs, which are now available in all Aerospike-supported clients at the General Availability level. Read our blog post for details.


#5

@renatomassaro,

Effective immediately, we will no longer actively support the LDT feature and will eventually remove the API. The exact deprecation and removal timeline will depend on customer and community requirements. Instead of LDTs, we advise that you use our newer List and SortedMap APIs, which are now available in all Aerospike-supported clients at the General Availability level. Read our blog post for details.