Jenkins build is back to normal : ActiveMQ-Trunk-Deploy #971

2014-06-20 Thread Apache Jenkins Server 
See

Jenkins build is back to normal : ActiveMQ-Trunk-Deploy ยป ActiveMQ #971

2014-06-20 Thread Apache Jenkins Server 
See

[jira] [Created] (AMQ-5237) Link stealing doesn't work for MQTT + Webscokets

2014-06-20 Thread Surf (JIRA) 
Surf created AMQ-5237:
-

 Summary: Link stealing doesn't work for MQTT + Webscokets
 Key: AMQ-5237
 URL: https://issues.apache.org/jira/browse/AMQ-5237
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0
 Environment: Java 7 , Windows server 2012 or Ubuntu 12.04
Reporter: Surf
Priority: Critical


Link stealing with existing clientid doesn't work for MQTT WS.
As per MQTT definition, same clientID should replace existing connection.

Simple testing: 
Connect with MQTT WS client library ( Eclipse Paho JS) and connect-disconnect 
multiple times. 
It will give error of client already connected. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5210) Concurrent connections with same clientid to network of brokers

2014-06-20 Thread Surf (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039003#comment-14039003
 ] 

Surf commented on AMQ-5210:
---

Hi [~dhirajsb],

I tried the same for MQTT. 
Any idea how we can implement this ?

Thank you

> Concurrent connections with same clientid to network of brokers
> ---
>
> Key: AMQ-5210
> URL: https://issues.apache.org/jira/browse/AMQ-5210
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.9.1
> Environment: Linux
>Reporter: Paddy
>
> Two brokers A and B connected to each other as networks of brokers setup.
> Connect a client with clientid C1 to broker A.
> Case1: When another client with same client id (C1) is connected to broker A, 
> it fails with exception ("already connected"), which is the expected behavior.
> Case2: When another client with same client id C1 is connected to broker B, 
> it does not fail. 
> Feature Request: Way to detect that there is an existing online connection 
> with the same clientid in the network bridge so that "already connected" 
> exception in Case2



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization

2014-06-20 Thread Surf (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038965#comment-14038965
 ] 

Surf commented on AMQ-5160:
---

Hi [~dhirajsb] and [~dejanb],

Is 5187 patch applied ?


> Wildcard subscriptions bypass Authentication / Authorization
> 
>
> Key: AMQ-5160
> URL: https://issues.apache.org/jira/browse/AMQ-5160
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.9.1
>Reporter: Surf
>Assignee: Dejan Bosanac
>Priority: Critical
>  Labels: authentication, authorization, mqtt, security
> Fix For: 5.10.0
>
> Attachments: activemq.xml, groups.properties, login.config, 
> patch.txt, users.properties
>
>
> I am using MQTT on AMQ 5.9.1
> After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT 
> retained messages.
> Simple case:
> Set Authentication / Authorization for two different TOPICS.
> Send retained message to one topic.
> Try to subscribe "#" with other second user.
> It will show retained messages published by TOPIC 1. 
> here i have attached test configurations.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[GitHub] activemq pull request: Wrap Zookeeper bundle

2014-06-20 Thread jbgeorg 
GitHub user jbgeorg opened a pull request:

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

Wrap Zookeeper bundle

ActiveMQ 5.10.0 fails with a class not found error when the zookeeper 
bundle is deployed as part of the activemq-client feature installation.

The Zookeeper bundle was wrapped in the features.xml in 5.9.1 but this 
seems to have been lost when the features were split into features-core & 
features.

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

$ git pull https://github.com/jbgeorg/activemq wrap_zookeeper_bundle

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

https://github.com/apache/activemq/pull/29.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 #29


commit 030fbb75b3b4d20ffc886c5be123545bdec13c58
Author: John Georgiadis 
Date:   2014-06-20T09:28:11Z

Wrap Zookeeper bundle




---
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.
---

[jira] [Commented] (AMQ-5235) erroneous temp percent used

2014-06-20 Thread anselme dewavrin (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038602#comment-14038602
 ] 

anselme dewavrin commented on AMQ-5235:
---

In fact I would greatly appreciate if an author confirms that the tempUsage is 
computed in
LevelDBClient.scala
at line :
  def size: Long = logRefs.size * store.logSize

Thank you in advance
Anselme

> erroneous temp percent used
> ---
>
> Key: AMQ-5235
> URL: https://issues.apache.org/jira/browse/AMQ-5235
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: debian (quality testing and production)
>Reporter: anselme dewavrin
>
> Dear all,
> We have an activemq 5.9 configured with 1GB of tempUsage allowed. Just by 
> security because we only use persistent messages (about 6000 messages per 
> day). After severall days of use, the temp usage increases, and even shows 
> values that are above the total amount of the data on disk. Here it shows 45% 
> of its 1GB limit for the following files :
> find activemq-data -ls
> 768098014 drwxr-xr-x   5 anselme  anselme  4096 Jun 19 10:24 
> activemq-data
> 768098134 -rw-r--r--   1 anselme  anselme24 Jun 16 16:13 
> activemq-data/store-version.txt
> 768098174 drwxr-xr-x   2 anselme  anselme  4096 Jun 16 16:13 
> activemq-data/dirty.index
> 768098114 -rw-r--r--   2 anselme  anselme  2437 Jun 16 12:06 
> activemq-data/dirty.index/08.sst
> 768098204 -rw-r--r--   1 anselme  anselme16 Jun 16 16:13 
> activemq-data/dirty.index/CURRENT
> 76809819   80 -rw-r--r--   1 anselme  anselme 80313 Jun 16 16:13 
> activemq-data/dirty.index/11.sst
> 768098220 -rw-r--r--   1 anselme  anselme 0 Jun 16 16:13 
> activemq-data/dirty.index/LOCK
> 76809810  300 -rw-r--r--   2 anselme  anselme305206 Jun 16 11:51 
> activemq-data/dirty.index/05.sst
> 76809821 2048 -rw-r--r--   1 anselme  anselme   2097152 Jun 19 11:30 
> activemq-data/dirty.index/12.log
> 76809818 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/dirty.index/MANIFEST-10
> 768098160 -rw-r--r--   1 anselme  anselme 0 Jun 16 16:13 
> activemq-data/lock
> 76809815 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 19 11:30 
> activemq-data/00f0faaf.log
> 76809823 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 16 11:50 
> activemq-data/00385f46.log
> 768098074 drwxr-xr-x   2 anselme  anselme  4096 Jun 16 16:13 
> activemq-data/00f0faaf.index
> 76809808  420 -rw-r--r--   1 anselme  anselme429264 Jun 16 16:13 
> activemq-data/00f0faaf.index/09.log
> 768098114 -rw-r--r--   2 anselme  anselme  2437 Jun 16 12:06 
> activemq-data/00f0faaf.index/08.sst
> 768098124 -rw-r--r--   1 anselme  anselme   165 Jun 16 16:13 
> activemq-data/00f0faaf.index/MANIFEST-07
> 768098094 -rw-r--r--   1 anselme  anselme16 Jun 16 16:13 
> activemq-data/00f0faaf.index/CURRENT
> 76809810  300 -rw-r--r--   2 anselme  anselme305206 Jun 16 11:51 
> activemq-data/00f0faaf.index/05.sst
> 76809814 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 12 21:06 
> activemq-data/.log
> 768098024 drwxr-xr-x   2 anselme  anselme  4096 Jun 16 16:13 
> activemq-data/plist.index
> 768098034 -rw-r--r--   1 anselme  anselme16 Jun 16 16:13 
> activemq-data/plist.index/CURRENT
> 768098060 -rw-r--r--   1 anselme  anselme 0 Jun 16 16:13 
> activemq-data/plist.index/LOCK
> 76809805 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/plist.index/03.log
> 76809804 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/plist.index/MANIFEST-02
> The problem is that in our production system it once blocked producers with a 
> tempusage at 122%, even if the disk was empty.
> So we invesigated and executed the broker in a debugger, and found how the 
> usage is calculated. If it in the scala leveldb files : It is not based on 
> what  is on disk, but on what it thinks is on the disk. It multiplies the 
> size of one log by the number of logs known by a certain hashmap.
> I think the entries of  the hashmap are not removed when the log files are 
> purged.
> Could you confirm ?
> Thanks in advance 
> Anselme



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5235) erroneous temp percent used

2014-06-20 Thread anselme dewavrin (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038587#comment-14038587
 ] 

anselme dewavrin commented on AMQ-5235:
---

Timothy,

Thank you for your answer and suggestion

We have the same behavior with 5.10 snapshot 20 december that we have in 
production.

Anselme

> erroneous temp percent used
> ---
>
> Key: AMQ-5235
> URL: https://issues.apache.org/jira/browse/AMQ-5235
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: debian (quality testing and production)
>Reporter: anselme dewavrin
>
> Dear all,
> We have an activemq 5.9 configured with 1GB of tempUsage allowed. Just by 
> security because we only use persistent messages (about 6000 messages per 
> day). After severall days of use, the temp usage increases, and even shows 
> values that are above the total amount of the data on disk. Here it shows 45% 
> of its 1GB limit for the following files :
> find activemq-data -ls
> 768098014 drwxr-xr-x   5 anselme  anselme  4096 Jun 19 10:24 
> activemq-data
> 768098134 -rw-r--r--   1 anselme  anselme24 Jun 16 16:13 
> activemq-data/store-version.txt
> 768098174 drwxr-xr-x   2 anselme  anselme  4096 Jun 16 16:13 
> activemq-data/dirty.index
> 768098114 -rw-r--r--   2 anselme  anselme  2437 Jun 16 12:06 
> activemq-data/dirty.index/08.sst
> 768098204 -rw-r--r--   1 anselme  anselme16 Jun 16 16:13 
> activemq-data/dirty.index/CURRENT
> 76809819   80 -rw-r--r--   1 anselme  anselme 80313 Jun 16 16:13 
> activemq-data/dirty.index/11.sst
> 768098220 -rw-r--r--   1 anselme  anselme 0 Jun 16 16:13 
> activemq-data/dirty.index/LOCK
> 76809810  300 -rw-r--r--   2 anselme  anselme305206 Jun 16 11:51 
> activemq-data/dirty.index/05.sst
> 76809821 2048 -rw-r--r--   1 anselme  anselme   2097152 Jun 19 11:30 
> activemq-data/dirty.index/12.log
> 76809818 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/dirty.index/MANIFEST-10
> 768098160 -rw-r--r--   1 anselme  anselme 0 Jun 16 16:13 
> activemq-data/lock
> 76809815 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 19 11:30 
> activemq-data/00f0faaf.log
> 76809823 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 16 11:50 
> activemq-data/00385f46.log
> 768098074 drwxr-xr-x   2 anselme  anselme  4096 Jun 16 16:13 
> activemq-data/00f0faaf.index
> 76809808  420 -rw-r--r--   1 anselme  anselme429264 Jun 16 16:13 
> activemq-data/00f0faaf.index/09.log
> 768098114 -rw-r--r--   2 anselme  anselme  2437 Jun 16 12:06 
> activemq-data/00f0faaf.index/08.sst
> 768098124 -rw-r--r--   1 anselme  anselme   165 Jun 16 16:13 
> activemq-data/00f0faaf.index/MANIFEST-07
> 768098094 -rw-r--r--   1 anselme  anselme16 Jun 16 16:13 
> activemq-data/00f0faaf.index/CURRENT
> 76809810  300 -rw-r--r--   2 anselme  anselme305206 Jun 16 11:51 
> activemq-data/00f0faaf.index/05.sst
> 76809814 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 12 21:06 
> activemq-data/.log
> 768098024 drwxr-xr-x   2 anselme  anselme  4096 Jun 16 16:13 
> activemq-data/plist.index
> 768098034 -rw-r--r--   1 anselme  anselme16 Jun 16 16:13 
> activemq-data/plist.index/CURRENT
> 768098060 -rw-r--r--   1 anselme  anselme 0 Jun 16 16:13 
> activemq-data/plist.index/LOCK
> 76809805 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/plist.index/03.log
> 76809804 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/plist.index/MANIFEST-02
> The problem is that in our production system it once blocked producers with a 
> tempusage at 122%, even if the disk was empty.
> So we invesigated and executed the broker in a debugger, and found how the 
> usage is calculated. If it in the scala leveldb files : It is not based on 
> what  is on disk, but on what it thinks is on the disk. It multiplies the 
> size of one log by the number of logs known by a certain hashmap.
> I think the entries of  the hashmap are not removed when the log files are 
> purged.
> Could you confirm ?
> Thanks in advance 
> Anselme



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (AMQ-5236) Shiro Authentication and Authorization for ActiveMQ's Jetty Instance

2014-06-20 Thread Claus Ibsen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/AMQ-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved AMQ-5236.
--

Resolution: Won't Fix

> Shiro Authentication and Authorization for ActiveMQ's Jetty Instance
> 
>
> Key: AMQ-5236
> URL: https://issues.apache.org/jira/browse/AMQ-5236
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: webconsole
>Affects Versions: 5.10.0
> Environment: Any
>Reporter: Justin Reock
>Priority: Minor
>  Labels: security
> Fix For: Unscheduled
>
>
> Shiro support for Authentication and Authorization was added to the ActiveMQ 
> 5.10.0 release.  Though the documentation states "The ActiveMQ Shiro plugin 
> can secure all aspects of ActiveMQ," significant work must be done to enable 
> support for authenticating into the web console, jolokia, and anything else 
> hosted by jetty in the broker.
> The jetty-realm.properties file is still authoritative, and the jetty.xml 
> configuration creates a security handler and loginService which will have to 
> be undone to allow Shiro to be authoritative.  
> My initial thought is to remove this authentication, and alter the web.xml 
> files of the existing webapps to use Shiro Filters, though this course of 
> action may change as more research is performed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (AMQ-5236) Shiro Authentication and Authorization for ActiveMQ's Jetty Instance

2014-06-20 Thread Claus Ibsen (JIRA) 

[ 
https://issues.apache.org/jira/browse/AMQ-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038565#comment-14038565
 ] 

Claus Ibsen commented on AMQ-5236:
--

It has never been the intention for ActiveMQ Broker security plugins to 
authenticate web apps. 

> Shiro Authentication and Authorization for ActiveMQ's Jetty Instance
> 
>
> Key: AMQ-5236
> URL: https://issues.apache.org/jira/browse/AMQ-5236
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: webconsole
>Affects Versions: 5.10.0
> Environment: Any
>Reporter: Justin Reock
>Priority: Minor
>  Labels: security
> Fix For: Unscheduled
>
>
> Shiro support for Authentication and Authorization was added to the ActiveMQ 
> 5.10.0 release.  Though the documentation states "The ActiveMQ Shiro plugin 
> can secure all aspects of ActiveMQ," significant work must be done to enable 
> support for authenticating into the web console, jolokia, and anything else 
> hosted by jetty in the broker.
> The jetty-realm.properties file is still authoritative, and the jetty.xml 
> configuration creates a security handler and loginService which will have to 
> be undone to allow Shiro to be authoritative.  
> My initial thought is to remove this authentication, and alter the web.xml 
> files of the existing webapps to use Shiro Filters, though this course of 
> action may change as more research is performed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)