date:20140805

[jira] [Commented] (SLING-3290) Long startup time with many vanityPath

2014-08-05 Thread Carsten Ziegeler (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085847#comment-14085847
 ] 

Carsten Ziegeler commented on SLING-3290:
-

I'm note sure if we should mix the two issues for now. As Felix points out, the 
long term goal is to just use /etc/map as the source of truth (some time ago I 
created SLING-3206 for a first step). Startup might still be slow if we have to 
traverse a large tree in /etc/map, so I think Antonio's idea of the bloom 
filter still makes sense.
Re guava: let's please not introduce this - if we require something from that 
lib, just embedd the single class you need, but I definitely don't want this 
lib as an OSGi bundle


 Long startup time with many vanityPath
 --

 Key: SLING-3290
 URL: https://issues.apache.org/jira/browse/SLING-3290
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Reporter: Antonio Sanso
Assignee: Antonio Sanso
  Labels: vanity
 Attachments: SLING-3290-patch.txt, StartupWithManyVanityPath.jpg


 When many vanityPath or alias are present the system take long time to 
 startup , Same when a vanityPath/alias is removed or updated .
 The reason behind is the usage of a query that updates the global mapentry.
 I have added a new Test to the performance test suite and this is the outcome
 {code}
 0 vanityPath  16ms
 1  vanityPath 19ms
 10 vanityPath 70ms
 100 vanityPath111ms
 1000 vanityPath   200ms
 1 vanityPath  1173ms
 3 vanityPath  3358ms
 {code}



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

[jira] [Commented] (SLING-3290) Long startup time with many vanityPath

2014-08-05 Thread Bertrand Delacretaz (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085852#comment-14085852
 ] 

Bertrand Delacretaz commented on SLING-3290:


FWIW I'm fine about embedding the relevant Guava (or other) code instead of 
having to install its bundle. What I object to is creating our own (or 
copy/pasted) bloom filter implementation, especially if there are no automated 
tests for it ;-)

 Long startup time with many vanityPath
 --

 Key: SLING-3290
 URL: https://issues.apache.org/jira/browse/SLING-3290
 Project: Sling
  Issue Type: Improvement
  Components: ResourceResolver
Reporter: Antonio Sanso
Assignee: Antonio Sanso
  Labels: vanity
 Attachments: SLING-3290-patch.txt, StartupWithManyVanityPath.jpg


 When many vanityPath or alias are present the system take long time to 
 startup , Same when a vanityPath/alias is removed or updated .
 The reason behind is the usage of a query that updates the global mapentry.
 I have added a new Test to the performance test suite and this is the outcome
 {code}
 0 vanityPath  16ms
 1  vanityPath 19ms
 10 vanityPath 70ms
 100 vanityPath111ms
 1000 vanityPath   200ms
 1 vanityPath  1173ms
 3 vanityPath  3358ms
 {code}



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

Re: Launchpad 7 Release?

2014-08-05 Thread Oliver Lietz

On Wednesday 23 July 2014 08:24:35 Bertrand Delacretaz wrote:
 On Tue, Jul 22, 2014 at 10:33 PM, Oliver Lietz apa...@oliverlietz.de 
wrote:
  On Tuesday 22 July 2014 13:30:59 Bertrand Delacretaz wrote:
  ...Are you planning to setup integration tests for that Karaf-based
  launcher?
  
  Sure. There are already basic bootstrap tests which check if the required
  bundles are available and active in org.apache.sling.launchpad.karaf-
  integration-tests and also some extended tests which check for services
  and nodes in the repository...
 
 Sorry my question was unclear - are you planning to run the
 launchpad/integration-tests on the Karaf-based launcher? So that the
 same test suite is used for that and for the launchpad.

SLING-3821 - some tests fail simply because required bundles are not present. 
I will add more bundles/features in the next days to fix them and come to you 
for some other failing tests as I'm not that familiar with the Sling test 
stuff.

  And there is sling-tests on GitHub.
 
 Where exactly? Not sure what that is.

https://github.com/oliverlietz/sling-tests

Was an easier and faster way for me to create tests with Pax Exam and Karaf 
instead of learning the Sling test stuff spread in different bundles in the 
repo. Should be easy for me to recreate them in launchpad/integration-tests 
when I'm done with SLING-3821.

O.

 -Bertrand

[jira] [Updated] (SLING-3502) Main job queue is not properly outdated

2014-08-05 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler updated SLING-3502:

Fix Version/s: Event 3.3.10

Main job queue is not properly outdated

Key: SLING-3502
URL: https://issues.apache.org/jira/browse/SLING-3502
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Event 3.3.10
Reporter: Marc Pfaff
Assignee: Stefan Egli
Fix For: Event 3.3.10

Attachments: SLING-3502-2.patch, SLING-3502-IT.patch,
SLING-3502.patch, SLING-3502.patch

The default job queue called main queue appears not to be properly outdated.
The JobManager keeps an internal map of currently running job queues, indexed
by job name. The code to outdate a queue (JobManagerImpl.outdateQueue()) uses
a filtered queue name to look up the queue to outdate in this map. But the
part that uses, creates and puts the queue on the map
(JobManagerImpl.process()), does not filter the queue name.
After outdating the main queue like this, there are two or more main queue
entries in the map, depending on the number of topology changes happening,
pointing to the same outdated queue instance. As one of the queues is still
indexed with main queue, new jobs that use the main queue are always
assigned an outdated queue. That's a dead end, as outdated queues do not
appear to have a queue thread running no more.
To reproduce:
* Start one instance
* Start a job that uses the main queue, so one instance of the main queue is
created. This job passes fine.
* Trigger a topology change, e.g. by adding a second instance to the same
topology
* Check the job manager in sling console, you should see two outdated main
queues, properly labeled as outdated, but one of them is internally still
indexed by main queue
* Start another job that uses the main queue. This job and all following jobs
using main queue never get executed

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

[jira] [Resolved] (SLING-3652) Sling Job Consumer Manager : Distribute config should be disabled by default

2014-08-05 Thread Carsten Ziegeler (JIRA)


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

Carsten Ziegeler resolved SLING-3652.
-

Resolution: Won't Fix

Closing as won't fix as this can be changed by applying an OSGi configuration

 Sling Job Consumer Manager : Distribute config should be disabled by default
 

 Key: SLING-3652
 URL: https://issues.apache.org/jira/browse/SLING-3652
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Event 3.3.10
Reporter: Ashutosh Shroti
Assignee: Amit Gupta

 Sling Job Consumer Manager service have an following flag:
 Distribute config - disabled
 This should be disabled by default.
 Use Case: While configuring author instances in the cluster, config changes 
 like disable the listener on topic com/adobe/granite/workflow/offloading 
 should be local to an instance. Hence above mentioned flag should be disabled 
 by default to prevent config changes to local instance. 



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

Re: Launchpad 7 Release?

2014-08-05 Thread Bertrand Delacretaz

Hi Oliver,

On Tue, Aug 5, 2014 at 8:57 AM, Oliver Lietz apa...@oliverlietz.de wrote:
 ...https://github.com/oliverlietz/sling-tests

 Was an easier and faster way for me to create tests with Pax Exam and Karaf
 instead of learning the Sling test stuff spread in different bundles in the
 repo. Should be easy for me to recreate them in launchpad/integration-tests
 when I'm done with SLING-3821

Ok, fair enough - what's important IMO is to run the exact same
integration tests suite in all environments, that is
launchpad/integration-tests. Note that those require the
launchpad/test-services bundle.

-Bertrand

[jira] [Reopened] (SLING-3652) Sling Job Consumer Manager : Distribute config should be disabled by default

2014-08-05 Thread Ashutosh Shroti (JIRA)


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

Ashutosh Shroti reopened SLING-3652:



Seems I had to elaborate the issue in detail:

Sling job consumer manager service has an configuration distribute config = 
disabled, which doesn't work as expected on start up. 

This config value needs to be reset (mark it enable  then disable) explicitly 
through OSGI config to get it reflected. 

Above issue should be fixed as it depicts confusing  un-expected behavior for 
an end user.


 Sling Job Consumer Manager : Distribute config should be disabled by default
 

 Key: SLING-3652
 URL: https://issues.apache.org/jira/browse/SLING-3652
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Event 3.3.10
Reporter: Ashutosh Shroti
Assignee: Amit Gupta

 Sling Job Consumer Manager service have an following flag:
 Distribute config - disabled
 This should be disabled by default.
 Use Case: While configuring author instances in the cluster, config changes 
 like disable the listener on topic com/adobe/granite/workflow/offloading 
 should be local to an instance. Hence above mentioned flag should be disabled 
 by default to prevent config changes to local instance. 



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

54 matches

Mail list logo