@Guido,
I just have quick look at the implementation of *MpscArrayQueue *methods
*offer,poll*. Don't you think below block keep the CPU in busy state ? I
see mainly WaitingStrategy are missing in MpscArrayQueue *,*and also i see
lot of features like event notification, pattern like chine of
responsibility missing in JCTools,Please correct me if I miss any thing
here ?
final long mask = this.mask;
final long capacity = mask + 1;
long consumerIndexCache = lvConsumerIndexCache(); // LoadLoad
long currentProducerIndex;
* do {*
currentProducerIndex = lvProducerIndex(); // LoadLoad
final long wrapPoint = currentProducerIndex - capacity;
if (consumerIndexCache <= wrapPoint) {
final long currHead = lvConsumerIndex(); // LoadLoad
if (currHead <= wrapPoint) {
return false; // FULL :(
} else {
// update shared cached value of the consumerIndex
svConsumerIndexCache(currHead); // StoreLoad
// update on stack copy, we might need this value again
if we lose the CAS.
consumerIndexCache = currHead;
}
}
* } while (!casProducerIndex(currentProducerIndex,
currentProducerIndex + 1));*
public E poll() {
final long consumerIndex = lpConsumerIndex();
final long offset = calcElementOffset(consumerIndex);
// Copy field to avoid re-reading after volatile load
final E[] buffer = this.buffer;
// If we can't see the next available element we can't poll
E e = lvElement(buffer, offset); // LoadLoad
if (null == e) {
/*
* NOTE: Queue may not actually be empty in the case of a
producer (P1) being interrupted after
* winning the CAS on offer but before storing the element in
the queue. Other producers may go on
* to fill up the queue after this element.
*/
if (consumerIndex != lvProducerIndex()) {
*do {*
e = lvElement(buffer, offset);
* } while (e == null);*
} else {
return null;
}
}
spElement(buffer, offset, null);
soConsumerIndex(consumerIndex + 1); // StoreStore
return e;
}
Regards,
Sampath
On Wed, Jan 27, 2016 at 3:31 AM, Remko Popma <[email protected]> wrote:
> To be honest, there would have to be a significant performance (or other)
> advantage in using JCTools. Otherwise users would simply be exchanging one
> dependency for another, I can't see the point of that...
>
> Remko
>
> Sent from my iPhone
>
> On 2016/01/27, at 0:42, Matt Sicker <[email protected]> wrote:
>
> It would be cool to see some JMH comparisons between the two approaches.
>
> On 26 January 2016 at 06:54, Guido Medina <[email protected]> wrote:
>
>> Well, this morning I got rid of Log4j2 asynchronous config and LMAX
>> dependency which combined with akka-log4j + log4j2 RollingRandomAccessFile
>> should give me a decent performance.
>>
>> On Tue, Jan 26, 2016 at 12:51 PM, Mikael Ståldal <
>> [email protected]> wrote:
>>
>>> It would be nice if you could leverage the asynchronicity of Akka while
>>> still using the Log4j 2 API.
>>>
>>> On Tue, Jan 26, 2016 at 1:50 PM, Mikael Ståldal <
>>> [email protected]> wrote:
>>>
>>>> I guess that if you would do all logging through Akka's actor logging,
>>>> they async logging of Log4j would be unnecessary since Akka gives you the
>>>> asynchronicity. But you probably like the Log4j 2 native API better than
>>>> Akka's logging API.
>>>>
>>>> On Tue, Jan 26, 2016 at 1:44 PM, Mikael Ståldal <
>>>> [email protected]> wrote:
>>>>
>>>>> I wasn't aware of this akka-log4j. Nice, I should try it to get rid of
>>>>> SLF4J.
>>>>>
>>>>> Perhaps there should be a page with links to this and similar other
>>>>> open source projects with explicit support of Log4j 2 somewhere on the
>>>>> Log4j web site?
>>>>>
>>>>> On Tue, Jan 26, 2016 at 1:18 PM, Guido Medina <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> I have both configured, for akka internal logging I'm using
>>>>>> akka-log4j extension:
>>>>>>
>>>>>> https://github.com/hseeberger/akka-log4j
>>>>>>
>>>>>> so that akka internal logging still uses my Log4j2 config but in my
>>>>>> code I'm using *LogManager.getLogger(...)* and for other APIs that
>>>>>> rely on Slf4j I have the jar bridge to Log4j2.
>>>>>> I'm using a RollingRandomAccessFile with all asynchronous appenders
>>>>>> including root.
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 9:08 AM, Mikael Ståldal <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Are you using Log4j together with Akka? Do you use the Log4j API
>>>>>>> directly, or through Akka's actor logging framework?
>>>>>>>
>>>>>>> On Mon, Jan 25, 2016 at 6:00 PM, Guido Medina <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm wondering if anyone would be willing to test the current LMAX
>>>>>>>> implementation vs JCTools specifically using the following class:
>>>>>>>>
>>>>>>>> I currently use them with Akka mailboxes, I tried LMAX once but
>>>>>>>> with some CPUs LMAX disruptor was behaving a bit weird which is why I
>>>>>>>> prefer Lamport's implementations of circular buffers that are very well
>>>>>>>> known and in use by Netty, Akka, etc.
>>>>>>>>
>>>>>>>> Or I could try and contribute by changing the LMAX for JCTools:
>>>>>>>>
>>>>>>>> JCtools-core dependency:
>>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> <groupId>org.jctools</groupId>
>>>>>>>> <artifactId>jctools-core</artifactId>
>>>>>>>> <version>1.1</version>
>>>>>>>> </dependency>
>>>>>>>>
>>>>>>>> Specific class that would replace LMAX disruptor:
>>>>>>>> https://github.com/JCTools/JCTools/blob/master/jctools-core/src/main/java/org/jctools/queues/MpscArrayQueue.java
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Guido.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> [email protected]
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>> reply email.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> [email protected]
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>
>>>>> Privileged and/or Confidential Information may be contained in this
>>>>> message. If you are not the addressee indicated in this message
>>>>> (or responsible for delivery of the message to such a person), you may
>>>>> not copy or deliver this message to anyone. In such case,
>>>>> you should destroy this message and kindly notify the sender by reply
>>>>> email.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> [email protected]
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> [email protected]
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>
>
> --
> Matt Sicker <[email protected]>
>
>
--
Regards,
Sampath
