Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Matt Pavlovich]

On 11/16/16 5:57 PM, Justin Bertram wrote:


0. isn't about auto-creation per-say, its about allowing protocol specific 
handlers to create address objects as needed for things like subscriptions.  
JMS durable subscription, MQTT retain, etc.

All of that is already in place.  To be clear, subscriptions are just queues 
(whether that's for JMS, STOMP, MQTT, etc.).

Rockin' =)


IHMO using the same prefix across protocols as much as possible would be super 
dope.

I think we'd want to make this configurable so that it would be up to users.

Are you saying support making it configurable for each individual protocol?

Other messaging systems (namely, IBM MQ Remote Queues, Cluster Queues) support 
fully qualified destination names.

This seems to me beyond the scope of this work.  The addressing improvements 
here are all intra-broker.  I'm in favor of keeping the work narrowly focused 
so our objectives remain clear.
I agree that remote broker addressing is out-of-scope for this first 
round of implementation. I'm suggesting it might make sense to at least 
accommodate it in the data model now, so there wouldn't be API breakage.


For example:
  "queue:///" as the prefix (or some other uri scheme w/ triple 
slashes) would support adding the remote broker part in later.


-Matt

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Justin Bertram]

0. Auto-creation for JMS queues and topics was already supported, and I expect 
that will continue.

1. I'm not sure I understand the use-case for having a topic and queue with the 
same name.  Can you clarify this?

2. I expect STOMP to have configurable multicast and anycast prefixes for 
destinations.  Whether users choose "/topic/" and "/queue/" for those 
respectively is up to them.  I'm not sure about AMQP.

3. I think using URIs has merit, but each protocol has nuances that would 
probably make something universal impossible.

4. See ARTEMIS-815 (sub-task of ARTEMIS-780).

5. Can you clarify this a bit more?  An example would be great.


Justin

- Original Message -
From: "Matt Pavlovich" 
To: dev@activemq.apache.org
Sent: Wednesday, November 16, 2016 12:23:11 PM
Subject: Re: [DISCUSS] Artemis addressing improvements, JMS component removal 
and potential 2.0.0

Hi Martin-

Glad to see this area getting dedicated attention. A couple things I 
didn't see covered in the doc or the JIRA comments. (I'll be adding to 
the JIRA comments as well.)

Items:

0. Pre-configuring destinations is a big brain drain, so anything that 
can be client-driven is a win. Also, protocol specific handlers could 
perform the admin operations on-demand.

For example:  session.createDurableSubscriber(...)   The JMS handler 
create the subscription on the behalf of the client.

1. Separate topic and queue namespaces.. in JMS topic:///foo != 
queue:///foo. The addressing will need some sort of way to separate the 
two during naming collisions.

2. In ActiveMQ 5.x, AMQP and STOMP handled the addressing by using 
queue:/// and topic:/// prefixes. I don't think that is necessarily a 
bad thing, but something to consider b/c we need to support #1

3. As far as destination behaviors, how about using uri parameters to 
pass provider (Artemis) specific settings on-the-fly?

 For example:  in AMPQ the address could be 
topic:///foo?type=nonSharedNonDurable etc..  same for MQTT, STOMP, etc.

 There is precedence in using uri parameters to configure the 
Destination in JMS as well. IBM MQ has 
session.createQueue("My.Queue?targetClient=1")

 Note: AMQP supports options as well, so that could be used as well. 
However, uri's tend to be better for externalizing configuration management.

4. Destination name separation b/w protocol handlers.  STOMP and MQTT 
like "/" and JMS likes "." as destination name separators. Is there any 
thought to having a native destination name separator and then have 
protocol-specific convertors?

5. Fully qualified destination names that include a broker name. Other 
providers support fully-qualified destination names in JMS following the 
format:  queue://$brokerName/$queueName. Adding this would go a long way 
to supporting migration of current applications without having to change 
client-code.

 Note: This would probably impact cluster handling as well, so 
perhaps in phase 1 there is just a placeholder for supporting a broker 
name in the future?

-Matt

On 11/16/16 10:16 AM, Martyn Taylor wrote:
> All,
>
> Some discussion has happened around this topic already, but I wanted to
> ensure that everyone here, who have not been following the JIRA/ARTEMIS-780
> branch has a chance for input and to digest the information in this
> proposal.
>
> In order to understand the motivators outlined here, you first need to
> understand how the existing addressing model works in Artemis. For those of
> you who are not familiar with how things currently work, I’ve added a
> document to the ARTEMIS-780 JIRA in the attachments section, that gives an
> overview of the existing model and some more detail / examples of the
> proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780
> *
>
> To summarise here, the Artemis routing/addressing model has some
> restrictions:
>
> 1. It’s not possible with core (and therefore across all protocols) to
> define ,at the broker side, semantics about addresses. i.e. whether an
> address behaves as a “point to point” or “publish subscribe” end point
>
> 2. For JMS destinations additional configuration and objects were added to
> the broker, that rely on name-spacing to add semantics to addresses i.e.
> “jms.topic.” “jms.queue.”  A couple of issues with this:
>
> 1.
>
> This only works for JMS and no other protocols
> 2.
>
> Name-spacing causes issues for cross protocol communication
> 3.
>
> It means there’s two ways of doing things, 1 for JMS and 1 for
> everything else.
>
> 3. The JMS and Core destination definitions do not have enough information
> to define more intricate behaviours. Such as whether an address should
> behave like a “shared subscription” or similar to a “volatile subscription”
> where clients don’t get messages missed when they are offline.
>
> 4. Some protocols (AMQP is a good example) don’t have enough information in
> their frames for 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Timothy Bish]

JMS is not a protocol

On 11/16/2016 01:39 PM, Justin Bertram wrote:

Some additional historical context from my personal observations...

The "jms.queue." and "jms.topic." queue/address prefixes were put in place 
years ago when the code-base was relatively young.  This was before my time but I believe this was 
done because it was an extremely simple (and effective) solution to the problem of how to provide 
different semantics between JMS and core.  JMS was the first and only non-core protocol supported 
by the broker for a long time.  As other protocols were implemented the whole prefix notion was 
recognized as a weakness (e.g. see ARTEMIS-203).  Since the donation to Apache significant work has 
been done on other protocols like AMQP, MQTT, and STOMP.  IMO, this has pressed the issue to the 
point of action.

I think making the changes that Martyn has outlined will provide a better 
foundation for the long-term of health of Artemis which is an increasingly 
multi-protocol broker.  It should make the broker simpler which will be a win 
for configuration as well as maintenance and new protocol integration.


Justin

- Original Message -
From: "Martyn Taylor" 
To: dev@activemq.apache.org
Sent: Wednesday, November 16, 2016 9:16:02 AM
Subject: [DISCUSS] Artemis addressing improvements, JMS component removal and 
potential 2.0.0

All,

Some discussion has happened around this topic already, but I wanted to
ensure that everyone here, who have not been following the JIRA/ARTEMIS-780
branch has a chance for input and to digest the information in this
proposal.

In order to understand the motivators outlined here, you first need to
understand how the existing addressing model works in Artemis. For those of
you who are not familiar with how things currently work, I’ve added a
document to the ARTEMIS-780 JIRA in the attachments section, that gives an
overview of the existing model and some more detail / examples of the
proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780
*

To summarise here, the Artemis routing/addressing model has some
restrictions:

1. It’s not possible with core (and therefore across all protocols) to
define ,at the broker side, semantics about addresses. i.e. whether an
address behaves as a “point to point” or “publish subscribe” end point

2. For JMS destinations additional configuration and objects were added to
the broker, that rely on name-spacing to add semantics to addresses i.e.
“jms.topic.” “jms.queue.”  A couple of issues with this:

1.

This only works for JMS and no other protocols
2.

Name-spacing causes issues for cross protocol communication
3.

It means there’s two ways of doing things, 1 for JMS and 1 for
everything else.

3. The JMS and Core destination definitions do not have enough information
to define more intricate behaviours. Such as whether an address should
behave like a “shared subscription” or similar to a “volatile subscription”
where clients don’t get messages missed when they are offline.

4. Some protocols (AMQP is a good example) don’t have enough information in
their frames for the broker to determine how to behave for certain
endpoints and rely on broker side configuration (or provider specific
parameters).

Proposal

What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get rid
of the JMS specific components and create a single unified mechanism for
configuring all types of endpoints across all protocols to define:

-

Point to point (queue)
-

Shared Durable Subscriptions
-

Shared Non Durable Subscriptions
-

Non Shared durable subscriptions
-

Non Shared Non durable subscriptions

To do this, the idea is to create a new “Address” configuration/management
object, that has certain properties such as a routing type which represents
how messages are routed to queues with this address.

When a request for subscription is received by Artemis, the relevant piece
can just look up the address and check it’s properties to determine how to
behave (or if an address doesn’t exist) then default to our existing
behaviour. For those interested in the details of how this might work I’ve
outlined some specific examples in the document on the JIRA.

What are the user impacts:

1. Configuration would need to be revised in order to expose the new
addressing object. I propose that we either continue supporting the old
schema for a while and/or provide a tool to migrate the configuration
schema.

2. Some new management operations would need to be added to expose the new
objects.

3. The JMS configuration and management objects would become obsolete, and
would need removing. The Broker side JMS resources were only a thin facade
to allow some JMS specific behaviour for managing destinations and for
things like registering objects in JNDI.

Broker side JNDI was removed in Artemis 1.0 in order to align 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Justin Bertram]

Some additional historical context from my personal observations...

The "jms.queue." and "jms.topic." queue/address prefixes were put in place 
years ago when the code-base was relatively young.  This was before my time but 
I believe this was done because it was an extremely simple (and effective) 
solution to the problem of how to provide different semantics between JMS and 
core.  JMS was the first and only non-core protocol supported by the broker for 
a long time.  As other protocols were implemented the whole prefix notion was 
recognized as a weakness (e.g. see ARTEMIS-203).  Since the donation to Apache 
significant work has been done on other protocols like AMQP, MQTT, and STOMP.  
IMO, this has pressed the issue to the point of action.

I think making the changes that Martyn has outlined will provide a better 
foundation for the long-term of health of Artemis which is an increasingly 
multi-protocol broker.  It should make the broker simpler which will be a win 
for configuration as well as maintenance and new protocol integration.


Justin

- Original Message -
From: "Martyn Taylor" 
To: dev@activemq.apache.org
Sent: Wednesday, November 16, 2016 9:16:02 AM
Subject: [DISCUSS] Artemis addressing improvements, JMS component removal and 
potential 2.0.0

All,

Some discussion has happened around this topic already, but I wanted to
ensure that everyone here, who have not been following the JIRA/ARTEMIS-780
branch has a chance for input and to digest the information in this
proposal.

In order to understand the motivators outlined here, you first need to
understand how the existing addressing model works in Artemis. For those of
you who are not familiar with how things currently work, I’ve added a
document to the ARTEMIS-780 JIRA in the attachments section, that gives an
overview of the existing model and some more detail / examples of the
proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780
*

To summarise here, the Artemis routing/addressing model has some
restrictions:

1. It’s not possible with core (and therefore across all protocols) to
define ,at the broker side, semantics about addresses. i.e. whether an
address behaves as a “point to point” or “publish subscribe” end point

2. For JMS destinations additional configuration and objects were added to
the broker, that rely on name-spacing to add semantics to addresses i.e.
“jms.topic.” “jms.queue.”  A couple of issues with this:

   1.

   This only works for JMS and no other protocols
   2.

   Name-spacing causes issues for cross protocol communication
   3.

   It means there’s two ways of doing things, 1 for JMS and 1 for
   everything else.

3. The JMS and Core destination definitions do not have enough information
to define more intricate behaviours. Such as whether an address should
behave like a “shared subscription” or similar to a “volatile subscription”
where clients don’t get messages missed when they are offline.

4. Some protocols (AMQP is a good example) don’t have enough information in
their frames for the broker to determine how to behave for certain
endpoints and rely on broker side configuration (or provider specific
parameters).

Proposal

What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get rid
of the JMS specific components and create a single unified mechanism for
configuring all types of endpoints across all protocols to define:

   -

   Point to point (queue)
   -

   Shared Durable Subscriptions
   -

   Shared Non Durable Subscriptions
   -

   Non Shared durable subscriptions
   -

   Non Shared Non durable subscriptions

To do this, the idea is to create a new “Address” configuration/management
object, that has certain properties such as a routing type which represents
how messages are routed to queues with this address.

When a request for subscription is received by Artemis, the relevant piece
can just look up the address and check it’s properties to determine how to
behave (or if an address doesn’t exist) then default to our existing
behaviour. For those interested in the details of how this might work I’ve
outlined some specific examples in the document on the JIRA.

What are the user impacts:

1. Configuration would need to be revised in order to expose the new
addressing object. I propose that we either continue supporting the old
schema for a while and/or provide a tool to migrate the configuration
schema.

2. Some new management operations would need to be added to expose the new
objects.

3. The JMS configuration and management objects would become obsolete, and
would need removing. The Broker side JMS resources were only a thin facade
to allow some JMS specific behaviour for managing destinations and for
things like registering objects in JNDI.

Broker side JNDI was removed in Artemis 1.0 in order to align with ActiveMQ
5.x style of client side JNDI.  These JMS pieces and their management
objects don't 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Matt Pavlovich]

Hi Martin-

Glad to see this area getting dedicated attention. A couple things I 
didn't see covered in the doc or the JIRA comments. (I'll be adding to 
the JIRA comments as well.)


Items:

0. Pre-configuring destinations is a big brain drain, so anything that 
can be client-driven is a win. Also, protocol specific handlers could 
perform the admin operations on-demand.


   For example:  session.createDurableSubscriber(...)   The JMS handler 
create the subscription on the behalf of the client.


1. Separate topic and queue namespaces.. in JMS topic:///foo != 
queue:///foo. The addressing will need some sort of way to separate the 
two during naming collisions.


2. In ActiveMQ 5.x, AMQP and STOMP handled the addressing by using 
queue:/// and topic:/// prefixes. I don't think that is necessarily a 
bad thing, but something to consider b/c we need to support #1


3. As far as destination behaviors, how about using uri parameters to 
pass provider (Artemis) specific settings on-the-fly?


For example:  in AMPQ the address could be 
topic:///foo?type=nonSharedNonDurable etc..  same for MQTT, STOMP, etc.


There is precedence in using uri parameters to configure the 
Destination in JMS as well. IBM MQ has 
session.createQueue("My.Queue?targetClient=1")


Note: AMQP supports options as well, so that could be used as well. 
However, uri's tend to be better for externalizing configuration management.


4. Destination name separation b/w protocol handlers.  STOMP and MQTT 
like "/" and JMS likes "." as destination name separators. Is there any 
thought to having a native destination name separator and then have 
protocol-specific convertors?


5. Fully qualified destination names that include a broker name. Other 
providers support fully-qualified destination names in JMS following the 
format:  queue://$brokerName/$queueName. Adding this would go a long way 
to supporting migration of current applications without having to change 
client-code.


Note: This would probably impact cluster handling as well, so 
perhaps in phase 1 there is just a placeholder for supporting a broker 
name in the future?


-Matt

On 11/16/16 10:16 AM, Martyn Taylor wrote:

All,

Some discussion has happened around this topic already, but I wanted to
ensure that everyone here, who have not been following the JIRA/ARTEMIS-780
branch has a chance for input and to digest the information in this
proposal.

In order to understand the motivators outlined here, you first need to
understand how the existing addressing model works in Artemis. For those of
you who are not familiar with how things currently work, I’ve added a
document to the ARTEMIS-780 JIRA in the attachments section, that gives an
overview of the existing model and some more detail / examples of the
proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780
*

To summarise here, the Artemis routing/addressing model has some
restrictions:

1. It’s not possible with core (and therefore across all protocols) to
define ,at the broker side, semantics about addresses. i.e. whether an
address behaves as a “point to point” or “publish subscribe” end point

2. For JMS destinations additional configuration and objects were added to
the broker, that rely on name-spacing to add semantics to addresses i.e.
“jms.topic.” “jms.queue.”  A couple of issues with this:

1.

This only works for JMS and no other protocols
2.

Name-spacing causes issues for cross protocol communication
3.

It means there’s two ways of doing things, 1 for JMS and 1 for
everything else.

3. The JMS and Core destination definitions do not have enough information
to define more intricate behaviours. Such as whether an address should
behave like a “shared subscription” or similar to a “volatile subscription”
where clients don’t get messages missed when they are offline.

4. Some protocols (AMQP is a good example) don’t have enough information in
their frames for the broker to determine how to behave for certain
endpoints and rely on broker side configuration (or provider specific
parameters).

Proposal

What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get rid
of the JMS specific components and create a single unified mechanism for
configuring all types of endpoints across all protocols to define:

-

Point to point (queue)
-

Shared Durable Subscriptions
-

Shared Non Durable Subscriptions
-

Non Shared durable subscriptions
-

Non Shared Non durable subscriptions

To do this, the idea is to create a new “Address” configuration/management
object, that has certain properties such as a routing type which represents
how messages are routed to queues with this address.

When a request for subscription is received by Artemis, the relevant piece
can just look up the address and check it’s properties to determine how to
behave (or if an address doesn’t exist) then default 

[DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Martyn Taylor]

All,

Some discussion has happened around this topic already, but I wanted to
ensure that everyone here, who have not been following the JIRA/ARTEMIS-780
branch has a chance for input and to digest the information in this
proposal.

In order to understand the motivators outlined here, you first need to
understand how the existing addressing model works in Artemis. For those of
you who are not familiar with how things currently work, I’ve added a
document to the ARTEMIS-780 JIRA in the attachments section, that gives an
overview of the existing model and some more detail / examples of the
proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780
*

To summarise here, the Artemis routing/addressing model has some
restrictions:

1. It’s not possible with core (and therefore across all protocols) to
define ,at the broker side, semantics about addresses. i.e. whether an
address behaves as a “point to point” or “publish subscribe” end point

2. For JMS destinations additional configuration and objects were added to
the broker, that rely on name-spacing to add semantics to addresses i.e.
“jms.topic.” “jms.queue.”  A couple of issues with this:

   1.

   This only works for JMS and no other protocols
   2.

   Name-spacing causes issues for cross protocol communication
   3.

   It means there’s two ways of doing things, 1 for JMS and 1 for
   everything else.

3. The JMS and Core destination definitions do not have enough information
to define more intricate behaviours. Such as whether an address should
behave like a “shared subscription” or similar to a “volatile subscription”
where clients don’t get messages missed when they are offline.

4. Some protocols (AMQP is a good example) don’t have enough information in
their frames for the broker to determine how to behave for certain
endpoints and rely on broker side configuration (or provider specific
parameters).

Proposal

What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get rid
of the JMS specific components and create a single unified mechanism for
configuring all types of endpoints across all protocols to define:

   -

   Point to point (queue)
   -

   Shared Durable Subscriptions
   -

   Shared Non Durable Subscriptions
   -

   Non Shared durable subscriptions
   -

   Non Shared Non durable subscriptions

To do this, the idea is to create a new “Address” configuration/management
object, that has certain properties such as a routing type which represents
how messages are routed to queues with this address.

When a request for subscription is received by Artemis, the relevant piece
can just look up the address and check it’s properties to determine how to
behave (or if an address doesn’t exist) then default to our existing
behaviour. For those interested in the details of how this might work I’ve
outlined some specific examples in the document on the JIRA.

What are the user impacts:

1. Configuration would need to be revised in order to expose the new
addressing object. I propose that we either continue supporting the old
schema for a while and/or provide a tool to migrate the configuration
schema.

2. Some new management operations would need to be added to expose the new
objects.

3. The JMS configuration and management objects would become obsolete, and
would need removing. The Broker side JMS resources were only a thin facade
to allow some JMS specific behaviour for managing destinations and for
things like registering objects in JNDI.

Broker side JNDI was removed in Artemis 1.0 in order to align with ActiveMQ
5.x style of client side JNDI.  These JMS pieces and their management
objects don't really do much, creating connection factories for instance
offers no functionality right now.  Going forward, users should be able to
use the core management API to do everything.

4. All client applications should behave exactly as they were before. The
proposal is for adding features to the core model, not removing any.  For
things like the Artemis JMS client which relied on name-spaces, they’ll be
a mechanism to define a name-spaced address and a mechanism to switch back
on name-spaces in the client.

5. Given some of the API changes and removal of the JMS specific pieces.
This would likely warrant a major bump. i.e. Artemis 2.0.0.

Whilst I’ve been looking at this, it’s become apparent, that the JMS pieces
have leaked into lots of areas of the code base, which does mean we’d need
to do a fair amount refactoring to move these bits to the new model.

In my opinion this proposal can only be a good thing. It creates a single
place (core) where all addressing objects are configured and managed and
allows all protocol managers to plug into the same mechanism. It solves
some of the cross protocol JMS → other protocols that we’ve seen users
struggle with, but still offers a way to support all the old behaviour in
client applications.

What are others thoughts on this? Any suggestions, comments 

[GitHub] activemq-artemis issue #889: ARTEMIS-852: Add PK and index to create journal...

[graben]

Github user graben commented on the issue:

https://github.com/apache/activemq-artemis/pull/889
  
to be honest, array idea is taken from ActiveMQ :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] LevelDB deprecation

[Jim Gomes]

No objections. I was never clear on what advantages LevelDB was supposed to
offer anyway.

On Wed, Nov 16, 2016, 3:45 AM Robbie Gemmell 
wrote:

> Seems like a good idea to me.
>
> On 15 November 2016 at 11:45, Christopher Shannon
>  wrote:
> > Hi Everyone,
> >
> > I just wanted to ask what people think about officially deprecating
> LevelDB
> > in our 5.x broker and update our documentation to say that it is no
> longer
> > recommended.  We can leave it in the code base for people who are still
> > using it but discourage its use.
> >
> > The main reason is that KahaDB continues to be the main focus where bugs
> > are fixed and not much attention is paid to LevelDB. There seems to be
> > several issues with corruption (especially with replication) so I don't
> > think it should be a recommended store unless the stability is sorted
> out.
> > Unfortunately nearly every Jira reported against LevelDB goes ignored.
> >
> > Now that Artemis exists and supports replication I think the focus should
> > be primarily on making Artemis the focus for users who need a replicated
> > store or to encourage the use of something like a shared file system
> > master/slave setup.
>

[GitHub] activemq-artemis pull request #888: ARTEMIS-851 Allowing broker configuratio...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/888


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #889: ARTEMIS-852: Add PK and index to create ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/889


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #889: ARTEMIS-852: Add PK and index to create ...

[clebertsuconic]

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/889#discussion_r88242343
  
--- Diff: 
artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/drivers/mysql/MySQLSQLProvider.java
 ---
@@ -36,8 +36,10 @@ private MySQLSQLProvider(String tName) {
  "(ID INTEGER NOT NULL AUTO_INCREMENT," +
  "FILENAME VARCHAR(255), EXTENSION VARCHAR(10), DATA LONGBLOB, 
PRIMARY KEY(ID)) ENGINE=InnoDB;";
 
-  createJournalTableSQL = "CREATE TABLE " + tableName +
- "(id BIGINT,recordType SMALLINT,compactCount SMALLINT,txId 
BIGINT,userRecordType SMALLINT,variableSize INTEGER,record LONGBLOB,txDataSize 
INTEGER,txData LONGBLOB,txCheckNoRecords INTEGER,seq BIGINT) ENGINE=InnoDB;";
+  createJournalTableSQL = new String[] {
+ "CREATE TABLE " + tableName + "(id BIGINT,recordType 
SMALLINT,compactCount SMALLINT,txId BIGINT,userRecordType SMALLINT,variableSize 
INTEGER,record LONGBLOB,txDataSize INTEGER,txData LONGBLOB,txCheckNoRecords 
INTEGER,seq BIGINT) ENGINE=InnoDB;",
+ "CREATE INDEX " + tableName + "_IDX ON " + tableName + " (id)"
--- End diff --

great idea to use arrays


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq pull request #212: AMQ-6506: Increase OSGi version range for packag...

[graben]

GitHub user graben opened a pull request:

https://github.com/apache/activemq/pull/212

AMQ-6506: Increase OSGi version range for package import javax.jms



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/graben/activemq AMQ-6506

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit 2b2d0983dbc969e38d4228f7ad7cbfeca81b44e3
Author: Benjamin Graf 
Date:   2016-11-16T12:57:42Z

AMQ-6506: Increase OSGi version range for package import javax.jms




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] LevelDB deprecation

[Robbie Gemmell]

Seems like a good idea to me.

On 15 November 2016 at 11:45, Christopher Shannon
 wrote:
> Hi Everyone,
>
> I just wanted to ask what people think about officially deprecating LevelDB
> in our 5.x broker and update our documentation to say that it is no longer
> recommended.  We can leave it in the code base for people who are still
> using it but discourage its use.
>
> The main reason is that KahaDB continues to be the main focus where bugs
> are fixed and not much attention is paid to LevelDB. There seems to be
> several issues with corruption (especially with replication) so I don't
> think it should be a recommended store unless the stability is sorted out.
> Unfortunately nearly every Jira reported against LevelDB goes ignored.
>
> Now that Artemis exists and supports replication I think the focus should
> be primarily on making Artemis the focus for users who need a replicated
> store or to encourage the use of something like a shared file system
> master/slave setup.

Re: [DISCUSS] LevelDB deprecation

[Jean-Baptiste Onofré]

+1

Regards
JB

⁣​

On Nov 16, 2016, 12:15, at 12:15, Dejan Bosanac  wrote:
>+1
>
>Regards
>--
>Dejan Bosanac
>http://sensatic.net/about
>
>On Wed, Nov 16, 2016 at 8:11 AM, Bennet Schulz 
>wrote:
>
>> +1
>>
>> > Am 15.11.2016 um 15:16 schrieb Clebert Suconic <
>> clebert.suco...@gmail.com>:
>> >
>> > +1
>> >
>> > On Tue, Nov 15, 2016 at 9:16 AM, Justin Bertram
>
>> wrote:
>> >> +1
>> >>
>> >> - Original Message -
>> >> From: "Christopher Shannon" 
>> >> To: dev@activemq.apache.org
>> >> Sent: Tuesday, November 15, 2016 5:45:41 AM
>> >> Subject: [DISCUSS] LevelDB deprecation
>> >>
>> >> Hi Everyone,
>> >>
>> >> I just wanted to ask what people think about officially
>deprecating
>> LevelDB
>> >> in our 5.x broker and update our documentation to say that it is
>no
>> longer
>> >> recommended.  We can leave it in the code base for people who are
>still
>> >> using it but discourage its use.
>> >>
>> >> The main reason is that KahaDB continues to be the main focus
>where bugs
>> >> are fixed and not much attention is paid to LevelDB. There seems
>to be
>> >> several issues with corruption (especially with replication) so I
>don't
>> >> think it should be a recommended store unless the stability is
>sorted
>> out.
>> >> Unfortunately nearly every Jira reported against LevelDB goes
>ignored.
>> >>
>> >> Now that Artemis exists and supports replication I think the focus
>> should
>> >> be primarily on making Artemis the focus for users who need a
>replicated
>> >> store or to encourage the use of something like a shared file
>system
>> >> master/slave setup.
>> >
>> >
>> >
>> > --
>> > Clebert Suconic
>>
>>

Re: [DISCUSS] LevelDB deprecation

[Dejan Bosanac]

+1

Regards
--
Dejan Bosanac
http://sensatic.net/about

On Wed, Nov 16, 2016 at 8:11 AM, Bennet Schulz 
wrote:

> +1
>
> > Am 15.11.2016 um 15:16 schrieb Clebert Suconic <
> clebert.suco...@gmail.com>:
> >
> > +1
> >
> > On Tue, Nov 15, 2016 at 9:16 AM, Justin Bertram 
> wrote:
> >> +1
> >>
> >> - Original Message -
> >> From: "Christopher Shannon" 
> >> To: dev@activemq.apache.org
> >> Sent: Tuesday, November 15, 2016 5:45:41 AM
> >> Subject: [DISCUSS] LevelDB deprecation
> >>
> >> Hi Everyone,
> >>
> >> I just wanted to ask what people think about officially deprecating
> LevelDB
> >> in our 5.x broker and update our documentation to say that it is no
> longer
> >> recommended.  We can leave it in the code base for people who are still
> >> using it but discourage its use.
> >>
> >> The main reason is that KahaDB continues to be the main focus where bugs
> >> are fixed and not much attention is paid to LevelDB. There seems to be
> >> several issues with corruption (especially with replication) so I don't
> >> think it should be a recommended store unless the stability is sorted
> out.
> >> Unfortunately nearly every Jira reported against LevelDB goes ignored.
> >>
> >> Now that Artemis exists and supports replication I think the focus
> should
> >> be primarily on making Artemis the focus for users who need a replicated
> >> store or to encourage the use of something like a shared file system
> >> master/slave setup.
> >
> >
> >
> > --
> > Clebert Suconic
>
>

[GitHub] activemq-artemis pull request #889: ARTEMIS-852: Add PK and index to create ...

[graben]

GitHub user graben opened a pull request:

https://github.com/apache/activemq-artemis/pull/889

ARTEMIS-852: Add PK and index to create journal table DDL script



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/graben/activemq-artemis ARTEMIS-852

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/889.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #889


commit 95e88dd22f68c27c57664cc5aec129f7f9175472
Author: Benjamin Graf 
Date:   2016-11-16T09:08:10Z

ARTEMIS-852: Add PK and index to create journal table DDL script




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---