We Keep Coding

Always getting error “Non HTTP response code: java.net.UnknownHostException”

I tried stress testing with JMeter software to test a web site as it crashed after a sms campaign. Currently site has been moved to a physical server.
I tested multiple times by adding threads, it worked and gave few errors (for above 1000 threads), and worked for 400 threads with no error. So I tried distributed testing with 4 PCs including my one.
After I tried again with only my PC to send requests to the site by adding 400 threads(ramp up = 1 , loop = 1). But each and every requests gives error. Then I tried using 1 thread. Same error was given.
I checked my network connection, and there is no problem. Then I browsed the web site "http://www.myjobs.lk/", and it works fine.
These are the values I have given in testing.
Under this condition, I cannot perform the testing because it always gives errors. How can I overcome this problem?

You're using incorrect JMeter configuration, change it as follows:
Remove http:// from "Server Name or IP" input
Put http to "Protocol input
It is also possible to have the full URL in "Path" field like
But using "http://" in "Server Name or IP" won't work.
Also once you defined hostname, port, path, etc. in HTTP Request Defaults it will be automatically applied to all HTTP Request Samplers. You will be able to override an option for particular this or that sampler but if you don't - default value will be used. See Why It's SO Important To Use JMeter's HTTP Request Defaults for more detailed explanation and some use cases.

For me it was helpful to setup proxy server:

Looks like JMeter tries to connect to myjobs.lk, and you browse to www.myjobs.lk. Try changing so that JMeter also connects to www.myjobs.lk

Trying to access Lotus DB via Java application - getting error msg " XXX.nsf has not been opened yet"

I'm trying to connect to a Lotus DB from an external Java application - my code works perfectly against a database located on my test (local) server, but fails when run against the production DB (no data is returned).
Diiop is running on the production server, and I have editor access for the production DB.
I'm able to create a session with the Domino server through my Java code, but am not able to open the Lotus DB.
Session session = NotesFactory.createSession("<Server>","UserID","password");
System.out.println("connected");
Database db = session.getDatabase("Server","<DB Path>" );
System.out.println("Access level: "+ db.getCurrentAccessLevel());
View vw = db.getView("Viewname");
After creating a session with the Domino server, I attempt to open the database, at which point I get the error XXX.nsf has not been opened yet.
I have also tried utilizing the IsOpen and open methods, with no luck.

Your database will not open in Java code, if its ACL forbids Internet access (that means http task). Check advanced tab of ACL, property "Maximum internet name and password". It should be at least Depositor to open it, or Reader to read data from it.

For diiop to work, the server has to have the allow HTTP clients to browse databases setting enabled. This setting is found in Server document->Internet Protocols->HTTP->R5 Basics. Of note, this setting takes effect even in modern Domino server instances. My guess is that the current value for this setting (set to "no") is where your problem is coming from.
You should also make sure that diiop is configured properly. The first test for this is to access http://hostname.domain.com/diiop_ior.txt. Accessing this URL should show you a page containing a simple text string containing something like 32 (seemingly) random characters.
I usually refer to this page when I need to get diiop working.

First try to access the database through a browser using the name/password in your code. If that doesn't work either HTTP isn't running or there is another issue separate to your code.
With issues like this I start with the sample code in the Infocenter.
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/topic/com.ibm.designer.domino.main.doc/H_EXAMPLES_GETDATABASE_METHOD_JAVA.html
eg.
Database db = session.getDatabase("<SERVER>", "<DBNAME>");
if (!db.isOpen())
System.out.println("DB does not exist.");
else
System.out.println("Title of database: \"" + db.getTitle()+ "\"") ;
See if that prints out anything.
The error message normally means the database is locked by the server, or corrupted. So try another database that you know you must have access to (eg. names.nsf ).

Just out of curiosity, what does printing :
session.getUserName();
..just before getCurrentAccessLevel() show? Is there an ambiguous username and you're ending up being authenticated as someone you don't expect?

I encountered the same error
Database xxx.nsf has not been opened yet
My problem was due to using a front slash instead of backslash. This corrected it:
var db = session.getDatabase(session.getServerName(), "path/dbname.nsf");
I noticed that nowhere in the above question is the db path identified, so perhaps the wrong slashes are being used.
The irritating part is that instead of returning an error message 'file not found' the NotesException message is pathdbname.nsf has not been opened yet when in fact it can't be found...

Mochahost GWT rpc and Servlet not working

While deploying my app to mochahost, I met the problem between servlet and GWT-RPC communicate. The error shows:
HTTP Status 404 - /403.shtml
type Status report
message /403.shtml
description The requested resource (/403.shtml) is not available.
.war file works perfectly on my workstation, but not working on mochahost.
Any ideas to solve it?
Thanks in advance.

Mochahost have a very good support, try livechatting with their tech department, you will probably have the thing solved.
That's what I do.

Make sure you update live site URL. For instance, generally, on local system you access web app as http://localhost:8080/myapp but, on server it changes to http://[www.]myapp.com. Again, this is just an instance. The point is, the live site must reflect correct URL from code (servlet/JSP/action/etc...) and configuration properties, if any.
Comment 'DirectoryIndex' property in .htaccess file if you do not have any index file.
Comment 'RewriteCond' property in .htaccess file if you do not have any rewrite requirement.
For sure, one of the reason - if client does not accept cookies and servlet does not encode URL.

How do I generate a Webservice Client in IntelliJ IDEA?

I have to set up a connection to a webservice that I don't own, all I have is a link to the WSDL file. The webservice has only one method, and I need access to it. I'm trying to use the standard "Generate Java Code from Wsdl or Wadl" (or create New->Web Service Client, which ends up in the same spot)
When I enter the URL I have, the status line says "Wsdl url connection exception". If I put the url in a browser, it nicely displays the xml file, so the URL works. I have a similar problem trying to generate the code in eclipse, where it also refuses to acknowledge the URL.
It's the first time I do anything webservice related and it's driving me mad, how do I fix this?

access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)

I have a Java Applet inserted on a simple HTML page located at http://localhost:8080/index.html:
<applet id="applet" code="SomeCode.class" archive="lib.jar" Width="1" Height="1"></applet>
The Java Applet has a method that looks similar to the code below:
public void PostStuffToServer() {
String server = "http://localhost:8080/PostHandler.ashx";
URL u = new URL(server);
URLConnection con = u.openConnection();
con.setDoOutput(true);
con.getOutputStream().write(stream.toByteArray());
con.connect();
}
When I execute the applet code from JavaScript like so:
obj = document.getElementById('applet');
obj.getClipboardImageURL();
I get the following error:
access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)
It seems like the Java code resolves the domain localhost to its equivalent IP address and therefore raises a cross domain security restrain. It works fine when I execute the same code from http://127.0.0.1:8080/index.html. The lib.jar file is signed.
Is there anyway to avoid this?

I encountered the same problem after installing Java 6 Update 22. My applet has been online for several years with no reported errors. When I downgrade to version 6 Update 21, everything works perfect. My applet is not signed.
SOLUTION:
It took me ha while to find the cause of the problem. Actually in my case there were several factors causing the security error. The problem was solved by the crossdomain.xml file. The Java applet tried to download the crossdomain file, failed, and did not even bother to display an error in the java console (debug level 5). Java tried to download the file from the ip adress of my domain (http://ip-address/crossdomain.xml), and not the root of my website (http://domain-name/crossdomain.xml). I guess it is better for the security aspect? I then had to configure the webserver to expose the crossdomainfile on the IP address. In my case I have removed the default website in ISS for security reasons, and had to create a new website. I then discovered that the java applet did not work with the crossdomain files i use with flash:
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-http-request-headers-from domain="*" headers="*"/>
<allow-access-from domain="*" />
</cross-domain-policy>
I had to remove the site-control and allow-http-request-headers-from nodes from the xml file in order to make the applet work.

I think I'm too late, but anyways... Guys you cannot believe how easy a solution this problem has.
The problem is that Java applet code called from JavaScript has only permissions that are the intersection of the JavaScript's code and your applet code - and somehow the JavaScript's permissions are seen as less, which results in this Exception.
Here is what I did: assume you have a function innocentFunc() that throws the java.net.SocketPermission exception, so your code is something like so:
String s = innocentFunc();
Now what you can do is to change it to something like so:
String s = AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
return innocentFunc();
}
}
);
This AccessController call basically states to the Java Virtual Machine that the code it runs should not obey to the permissions from the call chain, but rather only the caller's permissions in its own.
Of course, you should do something like this only after making sure that this innocentFunc call can't do anything bad, even if invoked by malicious code.

Just to add, there's some stuff here which exactly matches the issue I've been getting - it specifically mentions controlling an applet with JavaScript.
http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html
The fix for CVE-2010-3560 could cause
certain Java applets running in the
new Java Plug-in to stop working if
they are embedded in web pages which
contain JavaScript that calls into
Java in order to perform actions which
require network security permissions.
These applets may fail with a network
security exception under some
circumstances if the name service
which resolved the original web page
URL host name does not return a
matching name as the result of a
reverse address lookup.
Their suggestion is to add a special crazy just-for-Java A record to the DNS, like:
10.11.12.13 foo.bar.com.auth.13.12.11.10.in-addr.arpa

I'm getting the same thing with Update 22, and not Update 21.
I'm using the TinyPlayer applet, which I'm controlling via JavaScript.
I'm loading audio files from the same domain (mydomain.example.com, IP 1.2.3.4) as the page the applet is loading on - everything is referenced using relative URLs.
When I try to play the audio, it fails to play and I get:
access denied (java.net.SocketPermission 1.2.3.4:80 connect,resolve)
Looking at the access logs, I get a request for crossdomain.xml right before this happens. But the catch is that Java isn't asking for a crossdomain.xml from
mydomain.example.com/crossdomain.xml
...but instead from
1.2.3.4/crossdomain.xml
The workaround that seems to work for me is to set up a virtual host that responds for the IP address 1.2.3.4, and give it a crossdomain.xml, so that Java can find the crossdomain.xml in the (wrong) place that it's looking for it.
I just tested with the contents:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
...but it's probably possible to make this more restrictive.
With that in there, the audio plays correctly.

IIRC, the JavaScript same-origin policy prevents access to same-host/different-port. The PlugIn's LiveConnect enforces this policy for localhost only.

See: http://download.oracle.com/javase/tutorial/deployment/applet/security.html
Unsigned applets can perform the following operations:
They can make network connections to the host they came from.
If Java does not resolve the originating system to localhost then the applet will not be able to open sockets.

I had the similar issue and it only occurs when I use the "localhost" as a part of the URL for the page with the applet. When I used the URL with the actual host name or IP address as a part of the URL, the problem didn't happen. I am not sure this is a defect for the Java plug-in...
For example when I used the URL like http://localhost:9080/app_id/appletPage the problem occurred but when I use the URL by using the actual IP or host name, the problem did not occur.

I don't think is possible to made the crossdomain.xml file more restrictive, at current time Java applets only support the (domain="*")
see here http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML

You should check your virtual directory permissions.

Update from #Kristian above saved my day.
I had access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve) from an applet in a web application.
There had been change in our DNS, such that the IP of the load-balancer of the application server was not resolving to a name with domain. Therefore the suspected "cross-domain connection" from applet back to server was blocked.
I added crossdomain.xml with
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
to <tomcat-home>/webapps and checked that it is accessible with http://<server name>:<server port>/crossdomain.xml