@Cool--I look forward to experimenting with it!

But can you also confirm that the "instance" of Hazelcast the ODB uses is 
also available for me to use directly? Or is it "deeply embedded" and 
essentially inaccessible?
--Eric

On Thursday, July 16, 2015 at 11:45:42 PM UTC-5, l.garulli wrote:
>
> Hi Eric,
> You can definitely implement a distributed persistent queue using 
> OrientDB. I've just published a new page in documentation about it:
>
> http://orientdb.com/docs/last/Queue-use-case.html
>
> Best Regards,
>
> Founder & CEO
> OrientDB <http://orientdb.com/>
>
>
> On 17 July 2015 at 02:06, Eric24 <[email protected] <javascript:>> wrote:
>
>> So, MongoDB looks like a viable choice, but that means adding another 
>> technology to my "stack". Disque looks interesting, but seems a little to 
>> rough/early to consider right now. I'm still taking a deeper dive into 
>> Hazelcast (although there are some good articles on exactly this use-case, 
>> so that looks promising). But I'm curious--what would be the downside to 
>> implementing a queue in an ODB memory-storage document database, 
>> "replicated" across a few servers for redundancy? I need it to be reliable, 
>> but the messages are short-lived and so don't need to be persistent.
>> --Eric
>>
>>
>> On Wednesday, July 15, 2015 at 9:10:58 AM UTC-5, Eric24 wrote:
>>>
>>> Thanks for the suggestions. I'll check them out. Although my objective 
>>> was to not introduce yet another technology--that's why I was looking at 
>>> Hazelcast as a "next alternative", assuming ODB wasn't optimal for this. 
>>> Regarding Hazelcast, can you confirm my understanding that it's already 
>>> "included" with an ODB installation? And if so, can I access it directly?
>>> --Eric
>>>
>>>
>>> On Wednesday, July 15, 2015 at 1:44:04 AM UTC-5, tech support wrote:
>>>>
>>>> you can use a in memory grid hazelcast /gridgain , high performance 
>>>> distributed queue  
>>>>
>>>> On Wed, Jul 15, 2015 at 10:38 AM, Riccardo Tasso <[email protected]> 
>>>> wrote:
>>>>
>>>>> Please, consider also Disque:
>>>>>
>>>>> http://antirez.com/news/88
>>>>>
>>>>> Cheers,
>>>>>    Riccardo
>>>>> Il 15/lug/2015 05:50, "scott molinari" <[email protected]> ha 
>>>>> scritto:
>>>>>
>>>>>> Maybe you would want to look at MongoDB for this use case, as it is 
>>>>>> very special and Mongo fulfils it well. They have a collection type 
>>>>>> called 
>>>>>> Capped collections, which has a built in FIFO feature. It has a fixed 
>>>>>> size, 
>>>>>> so any data entering the collection causing it to grow larger than the 
>>>>>> fixed size means old data gets pushed out automatically. 
>>>>>>
>>>>>> https://docs.mongodb.org/manual/core/capped-collections/
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> --- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "OrientDB" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>  -- 
>>>>>
>>>>> --- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "OrientDB" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>  -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OrientDB" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to