I'm trying to test a kafka stream on jmeter using the pepper box config, but each time I try adding java request parameters it goes back to the default parameters without saving the ones I have added. I have tried the recommendations on here of adding the underscore, so _ssl.enabled, but the params are still disappearing. Any recommendations? Using jmeter5.3 and pepper-box1.0
I believe you need to put your SSL properties to the PepperBoxKafkaSampler directly, there are pre-populated placeholders which you can change and the changes persist.
The same behaviour is for Java Request Defaults
It might be the case your installation got corrupt somehow or there is a conflict with another JMeter Plugin, check jmeter.log file for any suspicious entries
In the meantime you may find Apache Kafka - How to Load Test with JMeter article useful
I had the same issue. I got around this issue by cloning the pepperbox repository https://github.com/GSLabDev/pepper-box and made changes to the PepperBoxKafkaSampler.java file, updated the setupTest() method with your props. You can also add the parameters making use of the .addArgument() method (used in PepperBoxKafkaSampler.java) to make the parameters available in jmeter.
Rebuild the repo using maven mvn clean install replace the old pepperbox jar in jmeter/lib/ext with your new built jar.
Related
I feel puzzled by the following behavior. In the very beginning of my main index.js, I am using
require('dotenv').config();
console.log(process.env); // everything seems in order
I know that the rest of my code successfully access all the relevant process.env.${VARS}. However, I get SSL exceptions; exceptions that I can easily solve by
export NODE_EXTRA_CA_CERTS=/some/absolute/path/to/ca.pem
npm start
Is there something special about NODE_EXTRA_CA_CERTS that would explained why this specific variable set with require('dotenv').config() does not work while the others work like a charm?
Does it need to be set before running npm? If it does, why is it the case and are there any workaround so I could keep thing simple?
environement:
dotenv 16.0.0
node v16.13.2
neardupe How to properly configure node.js to use Self Signed root certificates? .
Your problem is not in npm. npm start runs your application, typically (but not necessarily) by running node (or whatever spelling on your platform) to run your js code. When you use node to run js, NODE_EXTRA_CA_CERTS is read and saved in the C-code part of node at startup, before beginning to execute js, and subsequent changes in js variables like process.env do not affect it.
The clean way to do this in js is to pass the desired CAlist -- which can consist of the standard list (from tls.rootCertificates) plus any additions (or replacements or deletions) you choose -- in the (relevant) TLS socket creation, or any https request that implicitly creates a TLS socket; or alternatively to use --use-openssl-ca and select an OpenSSL-format store provided by your system (modified if necessary by system means like update-ca-certificates on Debian/Ubuntu) or one you create.
Or when using npm as you do, it should be possible to configure your package.json to set the envvar before running the application in node.
If you can't do either/any of those, especially where you control the toplevel (and startup) but call libraries you can't [safely] change, see the Q I linked above. For https connections that use the default https.globalAgent you can (documentedly) set that per the A. For all connections, you can monkeypatch tls.createSecureContext to use the undocumented context.addCACert as in the Q, which OP confirmed in the A does actually work if using a correct cert.
I am using selenium with browsermob-proxy, ultimately powered by "netty-all", to access a site (outside my control) which offers up enormous headers as part of its authentication process. Proxy fails with a netty error:
io.netty.handler.codec.TooLongFrameException: HTTP header is larger than 16384 bytes., version: HTTP/1.1
I need to remove all such limits from netty-alljar that my browsermob-proxy depends on, scalability, performance and memory conservation are not relevant in this use case.
Having cloned the repo, I changed:
DEFAULT_MAX_FRAME_SIZE in WebSocket00FrameDecoder (io.netty.handler.codec.http.websocketx)
HttpObjectDecoder default constructor in io.netty.handler.codec.http
to Integer.MAX_VALUE where appropriate.
However, even with these new settings it keeps throwing out "HTTP header is larger than 16384 bytes" in use.
Where else could this 16384 limit be coming from?
How does one remove it while retaining full functionality (at the acceptable cost to efficiency/memory usage etc)
Arrived at solution, its far from elegant but it works - my use case is inefficiency/fault tolerant so use with care.
I wont pollute this answer with Maven shenanigans as they are not strictly relevant, however, please note that netty-all by default pulls all of its components from the Maven repo. To change netty-all internals you will need to produce a jar of a required component (handler.codec.http in this case), then change pom.xml to pull in your modified jar. There are several methods to do this, the only one that worked for me was using mvn install to place the jar in the local .m2 repo:
mvn install:install-file -Dfile=netty-codec-http-4.1.25.Final-SNAPSHOT.jar -DgroupId=io.netty -DartifactId=netty-codec-http -Dversion=4.1.25.Final-SNAPSHOT -Dpackaging=jar
Then build netty-all to get the final jar, which you then use in your own project instead of the original.
Files modified to remove size limits from http operation:
all/pom.xml
codec-http/pom.xml
codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java
codec-http/src/main/java/io/netty/handler/codec/http/websocketx/WebSocket00FrameDecoder.java
codec-http/src/test/java/io/netty/handler/codec/http/HttpRequestDecoderTest.java
codec-http/src/test/java/io/netty/handler/codec/http/HttpResponseDecoderTest.java
Aside from setting various size restrictions to Integer.MAX_VALUE, I commented out relevant tests to ensure that Maven "package" command succeeds in producing the jar.
The git diff of the changes is available here:
https://gist.github.com/granite-zero/723fa55ae628494ff9b833dde1973a00
You could apply it as a patch to netty commit 04fac00c8c98ed26c5a75887c8e7e53b1e1b68d0
I recently moved our QA Rails application on to a new server due to a corrupt disk. However the asset pipeline now creates an empty Javascript file. This does not happen locally when running rake assets:precompile.
The file created is called public/assets/application-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.js`
The "e3b0c442" hash is the SHA-256 for an empty string.
Turns out we where using our own Javascript compressor, not the default one. Our compressor shells out to ugliferjs. Because it is a new server the latest version of ugliferjs was installed, via npm.
However one of the options we where passing to ugliferjs was no longer supported. It seems the errors, somewhere, was being silently swallowed.
Checking for the version of uglifierjs and passing different options for each fixed the issue.
I would like to run a local Monticello HTTP repository at work, so that we can share code easily among colleagues.
Is there a way to run something similar to SmalltalkHub privately?
EDIT:
I have tried all the options here and neither of them seems to work smoothly. Let me recap the options:
1) WebDAV on Apache, following Stuart. I have tried it, following some online guides. My current dav.conf looks like this:
DavLockDB /tmp/DavLock
Alias /pharo /opt/data/pharo
<Location /pharo>
Order Allow,Deny
Allow from all
Options Indexes MultiViews
Dav On
AuthType None
</Location>
I worked for a few days. Then suddenly I am not able to read new versions of a certain package. Whenever I write a version in an image and read it in another one, I get an exception ZnInvalidUTF8. I am not sure why, it may be that WebDAV has issues listing too many files?
2) Setting up my FTP. It seems to work, but when I try to set this repository as a remote in the versionner I get MCFtpRepository doesNotUnderstnd: #koRemote
3) SqueakSource3, following Tobias. I have tried running the two Gofer commands in both Pharo2 and Pharo3. In Pharo2 it does not load at all. In Pharo3, more or less everything works. I had to fix a few errors due to deprecated or removed messages, but in the end I am able to create projects and write to them.
The problem arises when I read. Apparently SS3 keeps some kind of internal cache. The result is that the list of packages I see on the project page is different from the list of packages that the client gets. The difference seems to be that the client requires a short version of the page, like http://localhost:8080/ss/MyProject/?C=M;O%3DD, and the results there are consistently less than in the full page http://localhost:8080/ss/MyProject.
Moreover, even on the project page, the list of versions remains cached until I navigate on a different project.
4) SmallTalkHub, following Sean. I have tried both using images from the INRIA server and images suggested from the Pharo-VM-loader (they may be the same).
I had to install Seaside again, since there was no ZnZincAdaptor in the downloaded image. I am now able to start SmallTalkHub, but as soon as I try to register a user, I get an error MessageNotUnderstood: receiver of "new" is nil. I am not able to track where this error comes from (is there a way to open a server-side debugger instead of returing 500 in Seaside?).
After this error, I can see a user both in mongodb and in the interface, but I am not able to login.
5) Git using filetree, as suggested by Kylon. This would prevent me from using MetaCello to handle dependencies and looks even more compelx than the other options.
At this point I am at a loss. :-( If I want to use Pharo, I will need to be able to collaborate with my colleagues. Using open source repositories is not an option, at least right now.
Is there a simple, tried and tested way to set up such a repository?
SqueakSource3 or SmallTalkHub would be even better, thanks to their user interfaces, but I really need at least basic collboration. Having an option that can run on a headless server would also be a big plus, as if this becomes a tool we use, it will not be doable to host the repository on my laptop.
Per this thread on the Pharo Dev mailing list:
Setting up the Server:
Download a SmalltalkHub image (https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/)
Install mongodb on your computer (for Debian: apt-get install mongodb)
Launch the SmalltalkHub image
Evaluate: ZnZincServerAdaptor startOn: 8080
Visit http://localhost:8080/tools/hub, create an account and a project
In addition to Sean's answer - if you just want a Metacello repository, and don't necessarily need the full SmalltalkHub stuff, then you just need a WebDav server. Apache will work fine, and I've even used Confluence's WebDAV support (with some tweaking) successfully in the past.
In addition to the other answers:
Just storing your versions in DropBox work very well!
You can also install SqueakSource3 (like SmalltalkHub, doesn't need MongoDB):
Gofer new
url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
package: 'ConfigurationOfSeaside3';
load.
((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load.
Gofer new
url:'http://www.squeaksource.com/MetacelloRepository';
package: 'ConfigurationOfSqueakSource';
load.
((Smalltalk at: #ConfigurationOfSqueakSource) project version: #bleedingEdge) load: #('All').
Then start your Adaptor (eg ZnZincServerAdaptor startOn: 8080) and goto http://localhost:8080/instalSS
Another way is go down the popular route of Git. I am using Github for my projects and it works great while Git itself works very well locally too. So if are already familiar with Git then its a very good choice
You can find more information here https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/GitAndPharo/GitAndPharo.pier.html
Sorry about the bad smalltalkhub experience. I have made some fixes to the configuration, and need to check if that is enough
I am using the latest (2014-01-03) Golang plugin for IntelliJ - for the first time.
Usually, my terminal workflow is to do go build && ./executable -args=1
So I am attempting to create a launch configuration to do the same thing, I took these actions:
Create a "Go Application" configuration
Fill in GOPATH/GOROOT environment variable
Fill in CLI arguments
Because there has to be a file to run, so I chose the one with func main()
Then there is a problem. When I run the configuration, the Golang plugin does not build the project, but instead builds the single script file with main method, then attempt to run it - obviously it does not work.
How to create a configuration equivelent of go build && ./executable -args=1?
Try to use the latest version from the official plugin manager.
If that doesn't work, please help us identify the issue by submitting a report here
Also, we are working hard to update the plugin with better type checks, debugging, go appengine support, improved formatter and much more but any help in improving the plugin is greatly appreciated.
Hope it helps.
However, I prefer to use goclipse which support auto-build, auto code completion and debug.