Re: DO NOT REPLY [Bug 41788] Log viewer (console window) needed as an option

2012-01-22 Thread Milamber


Le 22/01/2012 10:59, Philippe Mouawad a ecrit :
 Hello,
 As I fixed the pending issues (limit size to avoid OOM and fix
 enable/disable effect), I commited feature.
 Maybe we should add icon in toolbar ?
   

I don't think. Log viewer is a very useful behavior to help to debug
script (for example beanshell), but not for all activities with JMeter.

Milamber


 Regards
 Philippe

 On Sat, Jan 21, 2012 at 11:39 PM, Philippe Mouawad 
 philippe.moua...@gmail.com wrote:

   
 Hello guys,
 I wait for your feedback before commiting feature.

 Also note a little limitation, LogViewer misses Log Events until it's
 enabled by MaintFrame.


 Regards
 Philippe


 On Sat, Jan 21, 2012 at 11:37 PM, bugzi...@apache.org wrote:

 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=41788

 --- Comment #2 from Philippe Mouawad p.moua...@ubik-ingenierie.com 
 2012-01-21
 22:37:47 UTC ---
 Created attachment 28185
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=28185
 Screenshot

 --
 Configure bugmail:
 https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are the assignee for the bug.

   


 --
 Cordialement.
 Philippe Mouawad.




 

   



Re: svn commit: r1234482 - in /jmeter/trunk: docs/images/screenshots/changes/28_loggerpanel.png xdocs/changes.xml xdocs/images/screenshots/changes/28_loggerpanel.png

2012-01-22 Thread Milamber


Le 22/01/2012 10:55, pmoua...@apache.org a ecrit :
 Author: pmouawad
 Date: Sun Jan 22 10:55:34 2012
 New Revision: 1234482

 URL: http://svn.apache.org/viewvc?rev=1234482view=rev
 Log:
 Added new and noteworthy

 Added:
 jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png   (with 
 props)
 jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png   (with 
 props)
   

Perhaps, make a new screenshot with a beanshell example with a voluntary
mistake to show a example usage for the log viewer.
You can make 2 screenshots: one little to show menu option, one with the
example.

Milamber



 Modified:
 jmeter/trunk/xdocs/changes.xml

 Added: jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png?rev=1234482view=auto
 ==
 Binary file - no diff available.

 Propchange: jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png
 --
 svn:mime-type = application/octet-stream

 Modified: jmeter/trunk/xdocs/changes.xml
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1234482r1=1234481r2=1234482view=diff
 ==
 --- jmeter/trunk/xdocs/changes.xml (original)
 +++ jmeter/trunk/xdocs/changes.xml Sun Jan 22 10:55:34 2012
 @@ -187,6 +187,11 @@ Added DiskStore remote sample sender: li
  figure width=705 height=297 image=changes/25_selector.png/figure
  /p
  
 +h3New Logger Panel/h3
 +pA new visual components in the GUI that shows the log events.
 +figure width=1050 height=729 
 image=changes/28_loggerpanel.png/figure
 +/p
 +
  h3The menu item Options / Choose Language is now fully functional/h3
  p
  The menu item Options / Choose Language now changes all the displayed text 
 to the new language provided 

 Added: jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png?rev=1234482view=auto
 ==
 Binary file - no diff available.

 Propchange: jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png
 --
 svn:mime-type = application/octet-stream



   



Re: Properties files in mavenised artifacts

2012-01-22 Thread sebb
On 21 January 2012 22:55, Mark Collin m...@ardescosolutions.com wrote:
 I've been hunting through the mavenised artifacts available at:



 https://repository.apache.org/content/repositories/snapshots/org/apache/jmet
 er/



 However I cannot find the following in any package:



 saveservice.properties

 upgrade.properties

 system.properties

 jmeter.properties

 user.properties



 If I'm being blind please point me in the right direction, if I'm not being
 blind can we get these added to an artefact, or another artefact added that
 contains these.


You're right, those files are normally provided as part of the full
binary archive, which contains quite a few files in addition to the
jars.

Adding them to an existing jar may cause issues for non-Maven users,
so they need to be in a new artifact.
Possibly change parent to be a jar?

But having them in a jar would be a bit of a pain.
How do Maven applications manage configuration files normally?



 --

 Mark Collin

 Managing Director

 Ardesco Solutions Ltd



  mailto:m...@ardescosolutions.com m...@ardescosolutions.com



 Registered Office:

 The Coachhouse

 Greys Green Business Centre

 Henley-on-Thames

 Oxon

 RG9 4QG



 REGISTERED IN ENGLAND NO. 4837759




 --
 This message contains confidential information and is intended only for the 
 individual named. If you are not the named addressee you should not 
 disseminate, distribute or copy this e-mail. Please notify the sender 
 immediately by e-mail if you have received this e-mail by mistake and delete 
 this e-mail from your system. If you are not the intended recipient you are 
 notified that disclosing, copying, distributing or taking any action in 
 reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com


Re: Time for a release?

2012-01-22 Thread sebb
On 21 January 2012 17:12, Rainer Jung rainer.j...@kippdata.de wrote:
 On 21.01.2012 17:42, sebb wrote:

 I also want to add a signing target which can loop through all the
 dist artifacts (archives, poms, jars).

 That will need GPG installed, preferably GPG 2.x


 Note that Mark has added this feature to the Tomcat ant build just very
 recently. You can have a look.

Thanks, I did, but it seems to require the password to be defined on
the command-line.

I'm hoping to use the GPG agent to manage passwords.

 Regards,

 Rainer


Apache Excalibur Logger

2012-01-22 Thread Philippe Mouawad
Hello,
I noticed there was some plan to remove Excalibur logger dependency.
What is the new selected component to replace it ?

   - log4j
   - slf4J+logback


When do we plan this migration ?
Working on 41788
https://issues.apache.org/bugzilla/show_bug.cgi?id=41788I noticed
javadocs for excalibur where no more available on internet.

I suppose the same question will arise regarding DataBase Sampler pool.
What are the candidates:

   - Tomcat JDBC Pool :
   http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
   - Commons DBCP ?

I made some Load tests for an ECommerce site comparing the 2 pools and the
first one seems to be a little better performing (specially in exhaustion
cases)

although Commons DBCP quality is great.


-- 
Cordialement.
Philippe Mouawad.


Re: svn commit: r1234530 - in /jmeter/trunk: docs/images/screenshots/changes/ xdocs/ xdocs/images/screenshots/changes/

2012-01-22 Thread Milamber


Le 22/01/2012 15:56, milam...@apache.org a ecrit :
 Author: milamber
 Date: Sun Jan 22 15:56:06 2012
 New Revision: 1234530

 URL: http://svn.apache.org/viewvc?rev=1234530view=rev
 Log:
 Improve screenshots and add black borders
 Reduce menu Log viewer length
   

Philippe,

It's better to have screenshot with a minimum width for people with
small screen size.

I think the check box on menu Log viewer means enable/disable, it is
not needed to add this words with the label.

Milamber


 Modified:
 jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png
 jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel_option.png
 jmeter/trunk/xdocs/changes.xml
 jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png
 jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel_option.png

 Modified: jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel.png?rev=1234530r1=1234529r2=1234530view=diff
 ==
 Binary files - no diff available.

 Modified: 
 jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel_option.png
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/docs/images/screenshots/changes/28_loggerpanel_option.png?rev=1234530r1=1234529r2=1234530view=diff
 ==
 Binary files - no diff available.

 Modified: jmeter/trunk/xdocs/changes.xml
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1234530r1=1234529r2=1234530view=diff
 ==
 --- jmeter/trunk/xdocs/changes.xml (original)
 +++ jmeter/trunk/xdocs/changes.xml Sun Jan 22 15:56:06 2012
 @@ -188,11 +188,11 @@ Added DiskStore remote sample sender: li
  /p
  
  h3New Logger Panel/h3
 -pA new Log Viewer has been added to the GUI, useful to debug BeanShell 
 scripts for example:
 -figure width=1535 height=915 
 image=changes/28_loggerpanel.png/figure
 +pA new Log Viewer  has been added to the GUI and can be enabled from menu 
 Options  Log Viewer:
 +figure width=326 height=147 
 image=changes/28_loggerpanel_option.png/figure
  /p
 -pThis Low Viewer can be enabled from Options  Enable/Disable Log Viewer:
 -figure width=248 height=176 
 image=changes/28_loggerpanel_option.png/figure
 +pThis Log Viewer shows the jmeter.log file, and useful (for example) to 
 debug BeanShell/BSF scripts:
 +figure width=953 height=466 image=changes/28_loggerpanel.png/figure
  /p
  
  h3The menu item Options / Choose Language is now fully functional/h3

 Modified: jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel.png?rev=1234530r1=1234529r2=1234530view=diff
 ==
 Binary files - no diff available.

 Modified: 
 jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel_option.png
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/xdocs/images/screenshots/changes/28_loggerpanel_option.png?rev=1234530r1=1234529r2=1234530view=diff
 ==
 Binary files - no diff available.



   



Re: svn commit: r1234478 - in /jmeter/trunk: bin/ src/core/org/apache/jmeter/gui/ src/core/org/apache/jmeter/gui/action/ src/core/org/apache/jmeter/gui/util/ src/core/org/apache/jmeter/resources/ src/

2012-01-22 Thread Milamber
Philippe,

It's possible to include
JSplitPane topAndDown = new JSplitPane(JSplitPane.VERTICAL_SPLIT);
in setVisible true/false in
guiInstance.getLoggerPanel().setVisible(true);

In my opinion, it is not needed to see the vertical split all the time.

Thanks

Milamber

Le 22/01/2012 10:46, pmoua...@apache.org a ecrit :
 Author: pmouawad
 Date: Sun Jan 22 10:46:11 2012
 New Revision: 1234478

 URL: http://svn.apache.org/viewvc?rev=1234478view=rev
 Log:
 Bug 41788 - Log viewer (console window) needed as an option

 Added:
 jmeter/trunk/src/core/org/apache/jmeter/gui/LoggerPanel.java   (with 
 props)
 
 jmeter/trunk/src/core/org/apache/jmeter/gui/action/LoggerPannelEnableDisable.java
(with props)
 Modified:
 jmeter/trunk/bin/jmeter.properties
 jmeter/trunk/src/core/org/apache/jmeter/gui/GuiPackage.java
 jmeter/trunk/src/core/org/apache/jmeter/gui/MainFrame.java
 jmeter/trunk/src/core/org/apache/jmeter/gui/action/ActionNames.java
 jmeter/trunk/src/core/org/apache/jmeter/gui/util/JMeterMenuBar.java
 jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
 jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
 jmeter/trunk/src/jorphan/org/apache/jorphan/logging/LoggingManager.java
 jmeter/trunk/xdocs/changes.xml

 Modified: jmeter/trunk/bin/jmeter.properties
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1234478r1=1234477r2=1234478view=diff
 ==
 --- jmeter/trunk/bin/jmeter.properties (original)
 +++ jmeter/trunk/bin/jmeter.properties Sun Jan 22 10:46:11 2012
 @@ -121,6 +121,13 @@ jmeter.laf.mac=System
  # See https://issues.apache.org/bugzilla/show_bug.cgi?id=52026 for details
  # N.B. the laf can be defined in user.properties.
  
 +# LoggerPanel display
 +# default to false
 +jmeter.loggerpanel.display=true
 +# Max characters kept in LoggerPanel, default to 8 chars
 +# O means no limit
 +jmeter.loggerpanel.maxlength=5000
 +
  # Toolbar display
  # default:
  #jmeter.toolbar.display=true

 Modified: jmeter/trunk/src/core/org/apache/jmeter/gui/GuiPackage.java
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/gui/GuiPackage.java?rev=1234478r1=1234477r2=1234478view=diff
 ==
 --- jmeter/trunk/src/core/org/apache/jmeter/gui/GuiPackage.java (original)
 +++ jmeter/trunk/src/core/org/apache/jmeter/gui/GuiPackage.java Sun Jan 22 
 10:46:11 2012
 @@ -110,6 +110,17 @@ public final class GuiPackage implements
  
  /** The menu item toolbar. */
  private JCheckBoxMenuItem menuToolBar;
 +
 +/**
 + * The LoggerPanel menu item
 + */
 +private JCheckBoxMenuItem menuItemLoggerPanel;
 +
 +/**
 + * Logger Panel reference
 + */
 +private LoggerPanel loggerPanel;
 +
  
  /**
   * Private constructor to permit instantiation only from within this 
 class.
 @@ -729,4 +740,35 @@ public final class GuiPackage implements
  list.addAll(stoppables);
  return list;
  }
 +
 +/**
 + * Set the menu item LoggerPanel.
 + * @param menuItemLoggerPanel
 + */
 +public void setMenuItemLoggerPanel(JCheckBoxMenuItem 
 menuItemLoggerPanel) {
 +this.menuItemLoggerPanel = menuItemLoggerPanel;
 +}
 +
 +/**
 + * Get the menu item LoggerPanel.
 + *
 + * @return the menu item LoggerPanel
 + */
 +public JCheckBoxMenuItem getMenuItemLoggerPanel() {
 +return menuItemLoggerPanel;
 +}
 +
 +/**
 + * @param loggerPanel LoggerPanel
 + */
 +public void setLoggerPanel(LoggerPanel loggerPanel) {
 +this.loggerPanel = loggerPanel;
 +}
 +
 +/**
 + * @return the loggerPanel
 + */
 +public LoggerPanel getLoggerPanel() {
 +return loggerPanel;
 +}
  }
 \ No newline at end of file

 Added: jmeter/trunk/src/core/org/apache/jmeter/gui/LoggerPanel.java
 URL: 
 http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/gui/LoggerPanel.java?rev=1234478view=auto
 ==
 --- jmeter/trunk/src/core/org/apache/jmeter/gui/LoggerPanel.java (added)
 +++ jmeter/trunk/src/core/org/apache/jmeter/gui/LoggerPanel.java Sun Jan 22 
 10:46:11 2012
 @@ -0,0 +1,109 @@
 +/*
 + * Licensed to the Apache Software Foundation (ASF) under one or more
 + * contributor license agreements.  See the NOTICE file distributed with
 + * this work for additional information regarding copyright ownership.
 + * The ASF licenses this file to You under the Apache License, Version 2.0
 + * (the License); you may not use this file except in compliance with
 + * the License.  You may obtain a copy of the License at
 + *
 + *   http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * 

Re: Apache Excalibur Logger

2012-01-22 Thread sebb
On 22 January 2012 13:04, Philippe Mouawad philippe.moua...@gmail.com wrote:
 Hello,
 I noticed there was some plan to remove Excalibur logger dependency.
 What is the new selected component to replace it ?

   - log4j
   - slf4J+logback

Given that the main focus of JMeter is HTTP, and we use Apache
HttpClient, if we do replace logging it will be sensible to use the
same, i.e. Commons Logging.

But it is a huge job to do this; every single file that uses logging
will need to be updated.

As well as changing all the documentation, config files etc.


 When do we plan this migration ?

Not yet.

 Working on 41788
 https://issues.apache.org/bugzilla/show_bug.cgi?id=41788I noticed
 javadocs for excalibur where no more available on internet.

 I suppose the same question will arise regarding DataBase Sampler pool.
 What are the candidates:

   - Tomcat JDBC Pool :
   http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
   - Commons DBCP ?

I wonder whether there's really any point supporting database pooling
at all, given that the focus of JMeter is on independent test threads.

Adding pooling effectively means that JMeter is testing the pooling as
well as the database.

 I made some Load tests for an ECommerce site comparing the 2 pools and the
 first one seems to be a little better performing (specially in exhaustion
 cases)

 although Commons DBCP quality is great.

I don't think database pooling is really necessary for JMeter, so the
performance is not a big issue; tests that want to exercise a database
should not be using pooling - or at least should not be using a
pooling solution which is fixed by JMeter.

I don't know whether it's possible to create a datasource which
includes pooling, if so, then that is the way to go - i.e. support
data sources (I don't think we do currently).


 --
 Cordialement.
 Philippe Mouawad.


Re: Apache Excalibur Logger

2012-01-22 Thread Anthony Johnson
On Sun, Jan 22, 2012 at 8:29 PM, sebb seb...@gmail.com wrote:

 On 22 January 2012 13:04, Philippe Mouawad philippe.moua...@gmail.com wrote:
  Hello,
  I noticed there was some plan to remove Excalibur logger dependency.
  What is the new selected component to replace it ?
 
    - log4j
    - slf4J+logback

 Given that the main focus of JMeter is HTTP, and we use Apache
 HttpClient, if we do replace logging it will be sensible to use the
 same, i.e. Commons Logging.

 But it is a huge job to do this; every single file that uses logging
 will need to be updated.

 As well as changing all the documentation, config files etc.

 
  When do we plan this migration ?

 Not yet.

  Working on 41788
  https://issues.apache.org/bugzilla/show_bug.cgi?id=41788I noticed
  javadocs for excalibur where no more available on internet.
 
  I suppose the same question will arise regarding DataBase Sampler pool.
  What are the candidates:
 
    - Tomcat JDBC Pool :
    http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
    - Commons DBCP ?

 I wonder whether there's really any point supporting database pooling
 at all, given that the focus of JMeter is on independent test threads.


JMeter definitely needs persistent database connections which is
easily accomplished with database pooling.  JMeter loses usefulness if
it has to open a connection at sample time since this is a lot more
expensive than running optimized SQL.

Also, some database features rely on persistent connections to be
optimized such as PreparedStatement caches.

 Adding pooling effectively means that JMeter is testing the pooling as
 well as the database.

  I made some Load tests for an ECommerce site comparing the 2 pools and the
  first one seems to be a little better performing (specially in exhaustion
  cases)
 
  although Commons DBCP quality is great.

 I don't think database pooling is really necessary for JMeter, so the
 performance is not a big issue; tests that want to exercise a database
 should not be using pooling - or at least should not be using a
 pooling solution which is fixed by JMeter.

 I don't know whether it's possible to create a datasource which
 includes pooling, if so, then that is the way to go - i.e. support
 data sources (I don't think we do currently).

 
  --
  Cordialement.
  Philippe Mouawad.


Re: Properties files in mavenised artifacts

2012-01-22 Thread sebb
On 23 January 2012 01:03, sebb seb...@gmail.com wrote:
 On 22 January 2012 18:21, Mark Collin m...@ardescosolutions.com wrote:
 Parent sounds like a good place.

 Normally it would pick up things in src/main/resources, but as you don't
 have a maven directory structure I think you'll need to define a resource
 dir in the parent POM.  Something like this should work:

 resources
    resource
        directory${basedir}/bin/directory
        includes
            include**/*.properties/include
        /includes
    /resource
 /resources

 OK, thanks, I'll try that.

Just realised that won't work for creating the files to be uploaded,
as we don't use Maven to create the artifacts.

 I'm not sure exactly where you would need to place it in the artifact, I
 guess that depends on where you expect them to be when you read them in.

 JMeter expects to find them in the bin/ directory, i.e. where it finds
 ApacheJMeter.jar.

 However, I've no idea how any JMeter Maven launch plugins are intended
 to work so that may not be appropriate.

Sorry, but I've no idea how to make this work.

All I can suggest is creating a jar containing the missing properties
files (there are also some other missing files) which can be uploaded
as parent.

Whether that will be usable, I've no idea.

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 22 January 2012 11:42
 To: dev@jmeter.apache.org
 Subject: Re: Properties files in mavenised artifacts

 On 21 January 2012 22:55, Mark Collin m...@ardescosolutions.com wrote:
 I've been hunting through the mavenised artifacts available at:



 https://repository.apache.org/content/repositories/snapshots/org/apach
 e/jmet
 er/



 However I cannot find the following in any package:



 saveservice.properties

 upgrade.properties

 system.properties

 jmeter.properties

 user.properties



 If I'm being blind please point me in the right direction, if I'm not
 being blind can we get these added to an artefact, or another artefact
 added that contains these.


 You're right, those files are normally provided as part of the full binary
 archive, which contains quite a few files in addition to the jars.

 Adding them to an existing jar may cause issues for non-Maven users, so they
 need to be in a new artifact.
 Possibly change parent to be a jar?

 But having them in a jar would be a bit of a pain.
 How do Maven applications manage configuration files normally?



 --

 Mark Collin

 Managing Director

 Ardesco Solutions Ltd



  mailto:m...@ardescosolutions.com m...@ardescosolutions.com



 Registered Office:

 The Coachhouse

 Greys Green Business Centre

 Henley-on-Thames

 Oxon

 RG9 4QG



 REGISTERED IN ENGLAND NO. 4837759




 --
 This message contains confidential information and is intended only for
 the individual named. If you are not the named addressee you should not
 disseminate, distribute or copy this e-mail. Please notify the sender
 immediately by e-mail if you have received this e-mail by mistake and delete
 this e-mail from your system. If you are not the intended recipient you are
 notified that disclosing, copying, distributing or taking any action in
 reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only for the 
 individual named. If you are not the named addressee you should not 
 disseminate, distribute or copy this e-mail. Please notify the sender 
 immediately by e-mail if you have received this e-mail by mistake and delete 
 this e-mail from your system. If you are not the intended recipient you are 
 notified that disclosing, copying, distributing or taking any action in 
 reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com


buildbot failure in ASF Buildbot on jmeter-trunk

2012-01-22 Thread buildbot
The Buildbot has detected a new failure on builder jmeter-trunk while building 
ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/jmeter-trunk/builds/458

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch jmeter/trunk] 1234668
Blamelist: sebb

BUILD FAILED: failed shell_1 shell_2 shell_3

sincerely,
 -The Buildbot





Re: Apache Excalibur Logger

2012-01-22 Thread Anthony Johnson
On Sun, Jan 22, 2012 at 9:28 PM, sebb seb...@gmail.com wrote:
 On 23 January 2012 01:46, Anthony Johnson ans...@gmail.com wrote:
 On Sun, Jan 22, 2012 at 8:29 PM, sebb seb...@gmail.com wrote:

 On 22 January 2012 13:04, Philippe Mouawad philippe.moua...@gmail.com 
 wrote:
  Hello,
  I noticed there was some plan to remove Excalibur logger dependency.
  What is the new selected component to replace it ?
 
    - log4j
    - slf4J+logback

 Given that the main focus of JMeter is HTTP, and we use Apache
 HttpClient, if we do replace logging it will be sensible to use the
 same, i.e. Commons Logging.

 But it is a huge job to do this; every single file that uses logging
 will need to be updated.

 As well as changing all the documentation, config files etc.

 
  When do we plan this migration ?

 Not yet.

  Working on 41788
  https://issues.apache.org/bugzilla/show_bug.cgi?id=41788I noticed
  javadocs for excalibur where no more available on internet.
 
  I suppose the same question will arise regarding DataBase Sampler pool.
  What are the candidates:
 
    - Tomcat JDBC Pool :
    http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
    - Commons DBCP ?

 I wonder whether there's really any point supporting database pooling
 at all, given that the focus of JMeter is on independent test threads.


 JMeter definitely needs persistent database connections which is
 easily accomplished with database pooling.  JMeter loses usefulness if
 it has to open a connection at sample time since this is a lot more
 expensive than running optimized SQL.

 Also, some database features rely on persistent connections to be
 optimized such as PreparedStatement caches.

 JMeter uses persistent connections; the connection is established by:

 http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration

 This is a different matter from sharing connections between threads.

 The per-thread (non-shared) pool is currently implemented as a pool
 size of 1 per thread.


The preferred way(per the sarcastic why use pooling in the docs:-)
is not very nice code-wise.  If I have a 1,000 thread test then I will
have a 1,000 excaliber thread pool objects in memory and 1,000
per-thread poolMap objects.  Getting rid of pooling in JMeter would
definitely make this code better.

On the other hand, their are nice features from the pooling such as
connection testing, keep-alives and such.  Some of those would need to
be implemented if you guys decided to rip out pooling.

Regardless, you responded to my only concern and I learned
something(despite having written several JDBC Test Plans in the
past:-/)

 Adding pooling effectively means that JMeter is testing the pooling as
 well as the database.

  I made some Load tests for an ECommerce site comparing the 2 pools and the
  first one seems to be a little better performing (specially in exhaustion
  cases)
 
  although Commons DBCP quality is great.

 I don't think database pooling is really necessary for JMeter, so the
 performance is not a big issue; tests that want to exercise a database
 should not be using pooling - or at least should not be using a
 pooling solution which is fixed by JMeter.

 I don't know whether it's possible to create a datasource which
 includes pooling, if so, then that is the way to go - i.e. support
 data sources (I don't think we do currently).

 
  --
  Cordialement.
  Philippe Mouawad.


Re: Apache Excalibur Logger

2012-01-22 Thread Philippe Mouawad
Regarding logging,
It CAN Go fast if we share work and each of us takes one SRC folder.
It's à matter f search replace for 90%.


Regarding pool i am not sure to  there is an datasourceelemnt That has à
Maxpool property and looking at code it seemed the  excalibur datasource
was using this property.
Commons jdbc BasicDatasource was looking very close to it.

Regards
Philippe
On Monday, January 23, 2012, Anthony Johnson ans...@gmail.com wrote:
 On Sun, Jan 22, 2012 at 9:28 PM, sebb seb...@gmail.com wrote:
 On 23 January 2012 01:46, Anthony Johnson ans...@gmail.com wrote:
 On Sun, Jan 22, 2012 at 8:29 PM, sebb seb...@gmail.com wrote:

 On 22 January 2012 13:04, Philippe Mouawad philippe.moua...@gmail.com
wrote:
  Hello,
  I noticed there was some plan to remove Excalibur logger dependency.
  What is the new selected component to replace it ?
 
- log4j
- slf4J+logback

 Given that the main focus of JMeter is HTTP, and we use Apache
 HttpClient, if we do replace logging it will be sensible to use the
 same, i.e. Commons Logging.

 But it is a huge job to do this; every single file that uses logging
 will need to be updated.

 As well as changing all the documentation, config files etc.

 
  When do we plan this migration ?

 Not yet.

  Working on 41788
  https://issues.apache.org/bugzilla/show_bug.cgi?id=41788I noticed
  javadocs for excalibur where no more available on internet.
 
  I suppose the same question will arise regarding DataBase Sampler
pool.
  What are the candidates:
 
- Tomcat JDBC Pool :
http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
- Commons DBCP ?

 I wonder whether there's really any point supporting database pooling
 at all, given that the focus of JMeter is on independent test threads.


 JMeter definitely needs persistent database connections which is
 easily accomplished with database pooling.  JMeter loses usefulness if
 it has to open a connection at sample time since this is a lot more
 expensive than running optimized SQL.

 Also, some database features rely on persistent connections to be
 optimized such as PreparedStatement caches.

 JMeter uses persistent connections; the connection is established by:


http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration

 This is a different matter from sharing connections between threads.

 The per-thread (non-shared) pool is currently implemented as a pool
 size of 1 per thread.


 The preferred way(per the sarcastic why use pooling in the docs:-)
 is not very nice code-wise.  If I have a 1,000 thread test then I will
 have a 1,000 excaliber thread pool objects in memory and 1,000
 per-thread poolMap objects.  Getting rid of pooling in JMeter would
 definitely make this code better.

 On the other hand, their are nice features from the pooling such as
 connection testing, keep-alives and such.  Some of those would need to
 be implemented if you guys decided to rip out pooling.

 Regardless, you responded to my only concern and I learned
 something(despite having written several JDBC Test Plans in the
 past:-/)

 Adding pooling effectively means that JMeter is testing the pooling as
 well as the database.

  I made some Load tests for an ECommerce site comparing the 2 pools
and the
  first one seems to be a little better performing (specially in
exhaustion
  cases)
 
  although Commons DBCP quality is great.

 I don't think database pooling is really necessary for JMeter, so the
 performance is not a big issue; tests that want to exercise a database
 should not be using pooling - or at least should not be using a
 pooling solution which is fixed by JMeter.

 I don't know whether it's possible to create a datasource which
 includes pooling, if so, then that is the way to go - i.e. support
 data sources (I don't think we do currently).

 
  --
  Cordialement.
  Philippe Mouawad.


-- 
Cordialement.
Philippe Mouawad.


Re: New Maven targets

2012-01-22 Thread Milamber


Le 23/01/2012 01:09, sebb a ecrit :
 On 21 January 2012 19:07, Milamber milam...@apache.org wrote:
   

 Le 21/01/2012 16:42, sebb a ecrit :
 
 If you want to try out the Maven targets, update workspace and build
 (ant package)

 Then create the poms/jars:

 ant  _maven_dist -Djmeter.version=2.6-SNAPSHOT

 [might add this to the distribution target later]

 Then

 ant maven_upload

 will create the a local repo under target/deploy.

 If that works OK, then it is picking up Maven.

 You can then try uploading to the snapshots repo:

 ant maven_upload -DrepoType=snapshots

 I'm still working on the Maven bits, so the instructions may need to
 change slightly.

   
 It's works.
 My feedback:

 If you want to try out the Maven targets, update workspace and build
 (ant package)

 Note: Environment variable M2_HOME must be set.
 (In Eclipse, External Tools Configurations box  Ant Build maven task 
 Environment tab)
 (In command-line, declare an environment variable with export
 M2_HOME=/path/to/maven_home)
 
 I was assuming that people would run the Ant commands from a shell, in
 which case M2_HOME should already be set?
   

Both.
If you launch ant _dist_maven since command line, M2_HOME must be set.
or
If you launch _dist_maven since Eclipse, same thing with environment tab.


Command line error:
===
maven_upload:

BUILD FAILED
/home/milamber/temp/jmeter_2_6_SNAPSHOT/build.xml:1588: The following
error occurred while executing this line:
/home/milamber/temp/jmeter_2_6_SNAPSHOT/build.xml:1553:
/home/milamber/temp/jmeter_2_6_SNAPSHOT/${env.M2_HOME}/boot does not exist.
===


   
 Then create the poms/jars:

  ant _dist_maven -Djmeter.version=2.6-SNAPSHOT

 [might add this to the distribution target later]

 Then

  ant maven_upload -Djmeter.version=2.6-SNAPSHOT

 will create the a local repo under target/deploy.

 If that works OK, then it is picking up Maven.


 You can then try uploading to the snapshots repo:

 If needed, add or modify your $HOME/.m2/settings.xml with this lines :

 settings
 [...]
  servers
server
  idapache.snapshots.https/id !-- For Snapshots --
  usernameASF_Login/username
  passwordYour_Password/password
 
 Not a good idea to add your password in clear; see the Maven
 encryption features:

 http://maven.apache.org/guides/mini/guide-encryption.html
   


Done. Thanks for the URL.

Milamber


   
/server
server
  idapache.releases.https/id !-- For Releases --
  usernameASF_Login/username
  passwordYour_Password/password
/server
  /servers
 [...]
 /settings

 ant maven_upload -Djmeter.version=2.6-SNAPSHOT -DrepoType=snapshots


 Works:
 Repository Path:
 /org/apache/jmeter/ApacheJMeter/2.6-SNAPSHOT/ApacheJMeter-2.6-20120121.185244-4.pom
 Uploaded by:
 milamber
 Size:
 1.27 KB
 Uploaded Date:
 Sat Jan 21 2012 18:52:55 GMT+ (WET)
 Last Modified:
 Sat Jan 21 2012 18:52:55 GMT+ (WET)




 
 I also want to add a signing target which can loop through all the
 dist artifacts (archives, poms, jars).

 That will need GPG installed, preferably GPG 2.x

   

 gpg2 --version
 gpg (GnuPG) 2.0.14




 Milamber


 

   
 Milamber


 
 The script will need Maven 2.2.1 or Maven 3.0.4 (just released).

 See http://maven.apache.org/download.html



   
 Now, ant distribution task works fine in my machine, but I don't see
 maven section in output...


 
 I'm still working on it and have not committed it yet.



   
 Milamber



 
 If so which version?




   
 Milamber






 
 Regards
 Philippe

 On Thu, Jan 19, 2012 at 8:49 AM, Milamber milam...@apache.org wrote:





   
 Hello,

 I can act as a release manager for the 2.6 version.

 Milamber


 Le 15/01/2012 14:27, Milamber a ecrit :




 
 Le 15/01/2012 12:58, Rainer Jung a ecrit :





   
 Hello everyone,

 at the beginning of December 2011 we discussed, whether we should 
 have
 a release soon. I think the overall opinion was yes but it seems 
 the
 project is still busy with fixing things and adding enhancements.
 Nevertheless I have the impression there are now enough changes to
 warrant the next release and get all the nice new stuff out in 
 users
 hands. I don't know whether it should be a 2.5.2 or 2.6 though.





 
 +1 to release a new version 2.6

 Milamber






   
 Kudos to all the effort you put into JMeter!

 Regards,

 Rainer