JNI is a broad category - which really just means calling out from Java to
native O/S libraries.
If the library is intended as a holder for "any JNI needed by Artemis,"
then I don't see value in dis-associating it from Artemis. OTOH, if the
library has functionality that could be useful to other
That is correct. The JVM will die upon critical failures.
We should address it. But it makes it a minor issue.
It may be a bigger issue if the library is used outside of the context of
artemis. But as it’s currently used it’s a minor issue. We should address
it.
On Wed, Jan 30, 2019 at
onlyMIT commented on issue #2528: ARTEMIS-2226 last consumer connection should
close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#issuecomment-459215060
@michaelandrepearce @franz1981 This PR has updated.
Because of core modules should not know about
Currently it’s used for JNi operations around storage. Mostly libido. But
I foresee being used for other cases where we may need JNI.
On Wed, Jan 30, 2019 at 5:53 PM Arthur Naseef wrote:
> What is in the library?
>
> Art
>
>
> On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic <
>
I think that Otavio P on a recent PR has raised a similar question.
I think that's correct: we need to address a couple of changes to fix
cleanup on failures. The reason why they haven't been addressed is that a
critical I/O error could mean just JVM shutdown so the process's death
would release
Looking at the following file to understand the functionality of the
library, I have a question around the allocation and freeing of iocb's:
activemq-artemis/artemis-native/src/main/c/org_apache_activemq_artemis_jlibaio_LibaioContext.c
Function
What is in the library?
Art
On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic
wrote:
> I thought Since the native project had open scope like I'm proposing,
> it would eventually be useful anywhere that needs a JNI library.
>
> But we can go with activemq-artemis-native. That's fine.
>
> On
jbertram opened a new pull request #2532: ARTEMIS-2243 user/role ops for
PropertiesLoginModule via mgmnt
URL: https://github.com/apache/activemq-artemis/pull/2532
This is an automated message from the Apache Git Service.
To
asfgit closed pull request #2531: ARTEMIS-2205 Fixing Divert Example
URL: https://github.com/apache/activemq-artemis/pull/2531
This is an automated message from the Apache Git Service.
To respond to the message, please log
I thought Since the native project had open scope like I'm proposing,
it would eventually be useful anywhere that needs a JNI library.
But we can go with activemq-artemis-native. That's fine.
On Wed, Jan 30, 2019 at 12:51 PM jgenender wrote:
>
> Hey Clebert,
>
> This is really cool stuff. But
clebertsuconic opened a new pull request #2531: ARTEMIS-2205 Fixing Divert
Example
URL: https://github.com/apache/activemq-artemis/pull/2531
This is simply fixing the example under examples/features/standard/divert
Other tests are passing.
No additional tests are needed as the
Hey Clebert,
This is really cool stuff. But I don't like it being called ActiveMQ-native
because it will confuse people with ActiveMQ classic (which really is
ActiveMQ for now) or that it would even work with ActiveMQ 5.x. I would
recommend retaining the Artemis in the name, or
Say that a later point we add a new library to support a new device or
new native API.
I would prefer we still produce a new .SO for artemis. That is..
Artemis-Native-32.so and Artemis-Native-64.so. Just to make it
illustrative lets say we want to support MagneticTapes on the Journal.
The new
Also if others all prefer native and thats the consensus im not going to be
upset.
Sent from my Samsung Galaxy smartphone.
Original message From: "michael.andre.pearce"
Date: 30/01/2019 17:31 (GMT+00:00) To:
dev@activemq.apache.org Subject: Re: [DISCUSS] ActiveMQ Artemis
So i dislike native its just too generic for me.
I was just suggesting libaio an alternative. As i dont like saying no to
something without supplying an alternative.
I am open to other options.
Sent from my Samsung Galaxy smartphone.
Original message From: Clebert Suconic
Re the naming: native would be a module for all the sub component sharing
native interfaces of any kind. I prefer that too even if, effectively ATM
we will have just libAIO on it...
Il giorno mer 30 gen 2019 alle ore 18:18 Clebert Suconic <
clebert.suco...@gmail.com> ha scritto:
> I would not
I would not like to make the libaio part of the name. A similar
mistake happened on the Netty Project, when I tried to bring libaio
into netty. Their native library was for epoll at the time only and
that made things complicated at the time. They later made things more
generic but I never got to
Just on name front. I would call it activemq-libaio
Native is a bit too generic, it could mean support for epoll, kqueue or even
cpp client also.
Re vote, i think rather than a vote for this specific sub project. We should
decide on common guidelines for sub projects and rules for future, for me
Yes.. We should move the java part as well to be more reusable.
On Wed, Jan 30, 2019 at 11:51 AM michael.andre.pearce
wrote:
>
> Tbh, i see nothing wrong with making it a mini sub project. If anything
> having some sub projects is a good thing.
> Would the supporting java code be moved also?
>
> I don't think it as a separate project, just as a separate repository
with its own release cycle to make things easier.
I like the idea of a separate repository for that component and I like the
idea of a separate release cycle. From my POV, it seems that it would allow
it to evolve at it's own
+100 for this one and I would be pleased to do it, maybe with the help of
both Clebert and Otavio (that's quite good with native stuff!) :)
Obviously Michael you know that you're more then welcome on it as well eh,
I'm just taking the initiative :D
Il giorno mer 30 gen 2019 alle ore 17:51
One core bit would be that obviously we should ensure libaio is in disto so it
works out the box as it does today.
But i took this as given.
Sent from my Samsung Galaxy smartphone.
Original message From: "michael.andre.pearce"
Date: 30/01/2019 16:51 (GMT+00:00) To:
michaelandrepearce commented on a change in pull request #2529: Refactor the
native library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252344727
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a
Tbh, i see nothing wrong with making it a mini sub project. If anything having
some sub projects is a good thing.
Would the supporting java code be moved also?
And would we look to make the interfaces more generic?
Im keen if we separate something thats currently tighly embedded in artemis, we
clebertsuconic commented on a change in pull request #2529: Refactor the native
library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252339673
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a
michaelandrepearce commented on a change in pull request #2529: Refactor the
native library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252339116
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a
orpiske commented on a change in pull request #2529: Refactor the native
library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252338396
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a simple
One of the modules of ActiveMQ Artemis is the Native Layer:
https://github.com/apache/activemq-artemis/tree/056cee4183a048028c0a5417304eb89a540e1316/artemis-native
We currently hold all JNI Calls (pretty much libaio ATM).
It is stable and the release cycle is very long. Maybe one or two
changes
franz1981 edited a comment on issue #2479: ARTEMIS-2211 Refactor ByteBuffer
pooling, alignment and zeroing
URL: https://github.com/apache/activemq-artemis/pull/2479#issuecomment-459005431
@michaelandrepearce @clebertsuconic Yep, the CI has run on it and it is ok
:+1:
I will use it
clebertsuconic commented on a change in pull request #2529: Refactor the native
library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252335209
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a
orpiske commented on a change in pull request #2529: Refactor the native
library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252332040
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a simple
orpiske commented on a change in pull request #2529: Refactor the native
library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252329904
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a simple
franz1981 commented on issue #2479: ARTEMIS-2211 Refactor ByteBuffer pooling,
alignment and zeroing
URL: https://github.com/apache/activemq-artemis/pull/2479#issuecomment-459005431
@michaelandrepearce @clebertsuconic Yep, the CI has run on it and it is ok
:+1:
I will use it right
franz1981 edited a comment on issue #2479: ARTEMIS-2211 Refactor ByteBuffer
pooling, alignment and zeroing
URL: https://github.com/apache/activemq-artemis/pull/2479#issuecomment-459005431
@michaelandrepearce @clebertsuconic Yep, the CI has run on it and it is ok
:+1:
I will use it
clebertsuconic commented on a change in pull request #2529: Refactor the native
library build code
URL: https://github.com/apache/activemq-artemis/pull/2529#discussion_r252323631
##
File path: artemis-native/README.md
##
@@ -0,0 +1,87 @@
+# Introduction
+
+
+This is a
TomasHofman commented on issue #2287: ARTEMIS-2069 Backup doesn't activate
after shared store is reconnected
URL: https://github.com/apache/activemq-artemis/pull/2287#issuecomment-458960651
I see, it surprised me that checkstyle is off by default. Sent a fix.
orpiske commented on issue #2530: Native library fixes
URL: https://github.com/apache/activemq-artemis/pull/2530#issuecomment-458932091
As a matter of fact, io_queue_release [does seem to
orpiske edited a comment on issue #2530: Native library fixes
URL: https://github.com/apache/activemq-artemis/pull/2530#issuecomment-458929152
Also, when testing the change on the events structure, I think it unveils
another issue. Since libaioContext is allocated on the stack and
orpiske commented on issue #2530: Native library fixes
URL: https://github.com/apache/activemq-artemis/pull/2530#issuecomment-458929152
Also, when testing the change on the events structure, I think it unveils
another issue. Since libaioContext is allocated on the stack and initialized by
orpiske opened a new pull request #2529: Refactor the native library build code
URL: https://github.com/apache/activemq-artemis/pull/2529
This refactoring changes the native library build code to allow
cross-compilation and brings the following changes:
- Fix the link target to the
onlyMIT commented on a change in pull request #2528: ARTEMIS-2226 last consumer
connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252188228
##
File path:
michaelandrepearce commented on a change in pull request #2528: ARTEMIS-2226
last consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252179350
##
File path:
michaelandrepearce commented on a change in pull request #2528: ARTEMIS-2226
last consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252178820
##
File path:
michaelandrepearce commented on a change in pull request #2528: ARTEMIS-2226
last consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252177045
##
File path:
michaelandrepearce commented on a change in pull request #2528: ARTEMIS-2226
last consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252176199
##
File path:
onlyMIT commented on a change in pull request #2528: ARTEMIS-2226 last consumer
connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252172517
##
File path:
franz1981 commented on a change in pull request #2528: ARTEMIS-2226 last
consumer connection should close the previous consu…
URL: https://github.com/apache/activemq-artemis/pull/2528#discussion_r252156810
##
File path:
franz1981 commented on issue #2525: ARTEMIS-2241 Support direct deliver for
InVMAcceptors
URL: https://github.com/apache/activemq-artemis/pull/2525#issuecomment-458851977
@michaelandrepearce It seems good to me! I wanted the opinion of
@clebertsuconic too :)
If possible (just a
franz1981 commented on issue #2523: ARTEMIS-1977 ASYNCIO can reduce sys-calls
to retrieve I/O events
URL: https://github.com/apache/activemq-artemis/pull/2523#issuecomment-458851476
This PR doesn't change anything specific for being 32/64 bit, but like any
changes on the native layer,
franz1981 edited a comment on issue #2523: ARTEMIS-1977 ASYNCIO can reduce
sys-calls to retrieve I/O events
URL: https://github.com/apache/activemq-artemis/pull/2523#issuecomment-458851476
This PR doesn't change anything specific for being 32/64 bit, but like any
changes on the native
asfgit closed pull request #2524: ARTEMIS-2240 ActiveMQThreadPoolExecutor
should use LinkedTransferQueue
URL: https://github.com/apache/activemq-artemis/pull/2524
This is an automated message from the Apache Git Service.
To
asfgit closed pull request #2525: ARTEMIS-2241 Support direct deliver for
InVMAcceptors
URL: https://github.com/apache/activemq-artemis/pull/2525
This is an automated message from the Apache Git Service.
To respond to the
michaelandrepearce commented on issue #2523: ARTEMIS-1977 ASYNCIO can reduce
sys-calls to retrieve I/O events
URL: https://github.com/apache/activemq-artemis/pull/2523#issuecomment-458849490
So if this pr doesnt support cross compilation with out the other then for
me it cant be merged
53 matches
Mail list logo
