We Keep Coding

Start jmeter distributed testing from clouds

I want to run distributed load testing by jmeter, where servers(linux) are in the cloud and I have ability to start test from my local pc.
Is it even possible or client and servers should be in same subnet?
And in case its possible, may you provide me step by step guide how to achive this goal?
I have tired
https://jmeter.apache.org/usermanual/remote-test.html
https://cloud.google.com/community/tutorials/ssh-port-forwarding-set-up-load-testing-on-compute-engine?hl=ja
but I got error after error.
Before I disabled ssl verification, next error appeared:
error during JRMP connection establishment; nested exception is:
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
With disabled ssl verification I have next error:
Error in rconfigure() method java.rmi.MarshalException: error marshalling argume
nts; nested exception is:
java.net.SocketException: Connection reset by peer: socket write error
I have feeligs, like I making smth wrong with setting ip, port or firewall, but cant understand what

It is definitely possible to starts load agents (jmeter-server) from your local system. The only condition is that the traffic should not be blocked by firewall.
Based on your error, it looks like jmeter process is not having permission to open a port, port is already open (although there is a specific exception for this)
You can also try allowing all incoming traffic to your slaves (cloud linux boxes) and try running the test again.

According to the manual you mentioned all you need to do is just to take the following steps:
On your local machine set up the SSH tunnel:
ssh -L 24000:127.0.0.1:24000 -R 25000:127.0.0.1:25000 -L 26000:127.0.0.1:26000 username#hostname_of_cloud_machine
On the cloud machine launch the JMeter slave
./jmeter -s -Jserver.rmi.ssl.disable=true -Jserver_port=24000 -Jserver.rmi.localhostname=127.0.0.1 -Jserver.rmi.localport=26000 -j jmeter.log
Again on the local machine launch the JMeter master:
./jmeter -Jserver.rmi.ssl.disable=true -Jremote_hosts=127.0.0.1:24000 -Jclient.rmi.localport=25000 -Jmode=Statistical -n -t test.jmx -l result.jtl
You don't need to configure any firewalls as all the communication is happening over the SSH tunnel
More information:
Remote hosts and RMI configuration
Apache JMeter Properties Customization Guide

From locally I can access through teminal using psql command but not able to connect through JAVA code [duplicate]

This question already has answers here:
Connection refused (PGError) (postgresql and rails)
(6 answers)
Closed 9 years ago.
I am trying to connect postgresql but I am getting this error.
org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
My pg_hba.conf file is like this.
TYPE DATABASE USER CIDR-ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
I would be much obliged if anyone please be so kind enough to explain whats hoing on here and how should I correct it.

The error you quote has nothing to do with pg_hba.conf; it's failing to connect, not failing to authorize the connection.
Do what the error message says:
Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections
You haven't shown the command that produces the error. Assuming you're connecting on localhost port 5432 (the defaults for a standard PostgreSQL install), then either:
PostgreSQL isn't running
PostgreSQL isn't listening for TCP/IP connections (listen_addresses in postgresql.conf)
PostgreSQL is only listening on IPv4 (0.0.0.0 or 127.0.0.1) and you're connecting on IPv6 (::1) or vice versa. This seems to be an issue on some older Mac OS X versions that have weird IPv6 socket behaviour, and on some older Windows versions.
PostgreSQL is listening on a different port to the one you're connecting on
(unlikely) there's an iptables rule blocking loopback connections
(If you are not connecting on localhost, it may also be a network firewall that's blocking TCP/IP connections, but I'm guessing you're using the defaults since you didn't say).
So ... check those:
ps -f -u postgres should list postgres processes
sudo lsof -n -u postgres |grep LISTEN or sudo netstat -ltnp | grep postgres should show the TCP/IP addresses and ports PostgreSQL is listening on
BTW, I think you must be on an old version. On my 9.3 install, the error is rather more detailed:
$ psql -h localhost -p 12345
psql: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 12345?

Problems when trying to attach to a process using jdb

I need to attach a jdb debug session to a java application that is being executed in a remote host, but I am unable to do it. I am working on linux, with openjdk 1.8.0_65, 64-Bit Server VM.
What I have tried
In order to enable the port listening, I have run the java application adding the following arguments to the command line:
-Xdebug -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:8000,server=y,suspend=n
The following message is displayed in the console:
Listening for transport dt_socket at address: 8000
And the application starts running normally.
Then, from the remote host, I execute the following command:
> jdb -connect com.sun.jdi.SocketAttach:hostname=<remote_host>,port=8000
It fails, the output is:
java.net.ConnectException: Conexión rehusada
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[...]
Fatal error:
Unable to attach to target VM.
What I have checked
In order to check that the port is actually open and I can connect to it from the remote host, I have performed the following operations:
Lets call the host that is executing the java app. hostA, and the one from which I wan to attach the jdb hostB, then:
Check that there is actually a socket listening on port 8000 in hostA
> netstat -tualpn | grep :8000
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1399/<app_name>
In hostA, check that I can connect to the port 8000 (in other words, try to connect from the local host)
> nc -vz localhost 8000
nc: connect to localhost port 8000 (tcp) failed: Connection refused
Connection to localhost 8000 port [tcp/irdmi] succeeded!
With telnet, it seems that it can connect but the connection is closed as soon as it is stablished, maybe because the JVM is expecting some sort of request?
> telnet localhost 8000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
The java app. displays the following message when telnet connection is closed:
Debugger failed to attach: timeout during handshak
From hostB, check that I can connect to hostA, port 8000
> nc -vz hostA 8000
nc: connect to hostA port 8000 (tcp) failed: Connection refused
With telnet:
> telnet hostA 8000
Trying 172.17.10.127...
telnet: connect to address 172.17.10.127: Connection refused
So, I can't connect from hostA to hostB through the port 8000, although the JVM is listenning in the port 8000, in hostA.
Since the above fails, I have checked if the firewall is causing the connection refused. I have done it by using the nc command:
In hostA:
# First kill the java app (otherwise the port is busy), then:
> nc -l 8000
In hostB:
> nc -vz <hostA> 8000
Connection to hostA 8000 port [tcp/irdmi] succeeded!
As far as I understand, the above means that there is no firewall (or equivalent) blocking the port.
EDIT
Of course, I have tried to do jdb -attach but it fails even doing it from hostA.

I don't have enough points to comment. So I'm including this as an answer. It really isn't. BUT:
-Xdebug -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:8000,serv=y,suspend=n
Isn't it supposed to be:
-Xdebug -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:8000,server=y,suspend=n
??
[EDIT] You are probably already accounting for this - but also, if you are listening on 127.0.0.1, then it stands to reason that you won't connect from a remote computer. No doubt you are using an actual address, and just didn't include it here...

I have found the connection problem. In the command I use to launch the java application, I have changed the address parameter as following:
Before:
-Xdebug -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:8000,server=y,suspend=n
After (see address):
-Xdebug -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n

Trouble setting up a Transparent TCP Proxy on Android/Linux

I am trying to set up a transparent TCP proxy on Android for my dissertation, but am having some issues. I am using software that I found on this site - http://en.dfr.ch/free-software/java-tcp-proxy - the source is freely available.
I have extracted the source and created an Android application from it. The main bulk of the code is in the below loop.
while(!interrupted()) {
Socket serverSocket=srvSock.accept();
Log.e(TAG, "New incoming connection");
try {
serverSocket.setSoLinger(true,lingerTime);
Socket clientSocket=new Socket(dstAddr,dstPort);
clientSocket.setSoLinger(true,lingerTime);
Log.e(TAG, "Server socket and client socket created");
StreamCopyThread sToC=new StreamCopyThread(serverSocket,clientSocket, "BrowserSide");
StreamCopyThread cToS=new StreamCopyThread(clientSocket,serverSocket, "ServerSide");
Log.e(TAG, "Working threads created");
sToC.setPeer(cToS);
cToS.setPeer(sToC);
Log.e(TAG, "Peers defined");
synchronized(lock) {
connections.addElement(cToS);
connections.addElement(sToC);
sToC.start();
cToS.start();
Log.e(TAG, "Working threads running");
}
} catch(Exception xc) {
Log.e(TAG, header+":"+xc.getMessage());
// xc.printStackTrace();
}
}
srvSock.close();
Traffic is redirected from an IP to localhost where the proxy handles it. To do the redirect, I have used the following iptables rule:
iptables -t nat -A OUTPUT -p tcp --dport 80 -d [any ip] -j REDIRECT --to-port 8080
This seems to work in redirecting the traffic, however when the proxy is running, it seems to continuously creates new threads (connections) until it runs out of memory. With the logging, the output it similar to below. Where ... represents several loops of the above output logging before the error.
Working threads running
New incoming connection
Server socket and client socket created
Working threads created
Peers defined
BrowserSide-->611
Working threads running
...
/127.0.0.1:8080 <-> /[any ip]:80:Too many open files
I am really confused as to why it's not working properly. The same error appears when I try it in Ubuntu on a computer, but it works perfectly fine in Windows. I am thinking it may be an issue with iptables or some jvm/socket based issues in Linux. I am currently running iptables version 1.4.4.
Thank you in advance for taking your time to have a look at this problem.

You are more than likely initiating a connection in your code to the same port that is being redirected.
Consider:
iptables -t nat -I OUTPUT -p tcp --dport 80 -d [any ip] -m owner \! --gid-owner proxyrunner -j REDIRECT --to-port 8080
This will exclude programs running as group proxyrunner, make sure to execute your proxy accordingly:
sg proxyrunner 'java [...]'

Have you tried to run other Java proxies such as Little proxy with the same configuration?
http://dev.littleshoot.org/littleproxy/
Other open source proxies: http://proxies.xhaus.com/java/

Access RMI Port from remote using iptables

I want to access an RMI-Service from a remote Server.
Locally everything works fine. But from the remote side i get the following exception:
java.net.ConnectException: Connection timed out
I used IP-Tables, that the server believes the request comes to 127.0.0.1 and not to the public ip address xx.yy.zz
iptables -t nat -A PREROUTING -p tcp -d xx.yy.zz --dport 1099 -j DNAT --to-destination 127.0.0.1:1099
The server is started with "-Djava.rmi.server.hostname=127.0.0.1" as JVM-Argument.
Regards,
Markus

For me this looks like misuse of iptables. Do the following:
Make sure your application binds to the public address. For example by removing "-Djava.rmi.server.hostname=127.0.0.1".
If you still can't reach your app. Add a firewall rule to iptables something like:
$iptables -A INPUT -p tcp --dport 1099 -j ACCEPT

I suspect the DNAT only changes the destination of the packet, rather than the source. Wouldn't it make a lot more sense to make the RMI server accept packets from a trusted LAN or VPN, instead of trying to rewrite the packets using iptables?