I have error HTTP: 500 when I try to upload a file or to share one in the white board.
I install openmeetings on windows 7 64 bits and I configured all things perfectly with compatible versions:
C:\ffmpeg\bin
C:\ImageMagick-6.6.4
C:\Program Files (x86)\SWFTools
C:\sox-14.4.0
C:\jodconverter-core-3.0-beta-4\lib
recording and video conference works perfectly.
How can I solve this problem ? Is there a problem with the SWFTools version 0.9.1 ?
When you import a document you should have a look at the error message / convertion message.
OpenMeetings has mailing lists where those problems are discussed:
http://incubator.apache.org/openmeetings/mail-lists.html
Were you running it in proxied mode on port 8080 (The default port of OpenLaszlo proxied mode)? If so, some routers/firewalls block this port. I encountered a similar problem myself when my boss and I were at a conference and that was the cause of the problem.
We have since changed our demo application to SOLO (no-proxied mode) which has solved our problem.
Related
I'm trying to clone and build a GitHub repo using Bazel, but a dependency requires an old verson of zlib via an outdated URL. I've already spent a few hours trying to do things like messing with the /etc/hosts file and running a web server to get it to work. I've gotten zlib.net to point to localhost, then running a web server on localhost:80 with zlib at the correct path, but that's not working, since the request is timing out.
I've googled it and only about 3 remotely relevant results have popped up, none of which are helpful.
How do I get it to build?
This is the error:
Error in download_and_extract: java.io.IOException: Error downloading [https://zlib.net/zlib-1.2.11.tar.gz] to /private/var/tmp/_bazel_user/37df51594c7eac8a62dd677a22c5514b/external/zlib/temp16216011345324291299/zlib-1.2.11.tar.gz: GET returned 404 Not Found
It is timing out because the request uses HTTPS, which is port 443, not HTTP on port 80. You can use a similar approach to what you are doing (with the hosts file) but just run a HTTPS server on port 443.
This can be achieved using tools such as ngrok and your current localhost web server.
Yesterday if was opening http://my-ip:3000/solr then the home page is opening of Solr.
But today I restarted VM after that is showing me like that.
HTTP ERROR: 404
Problem accessing /solr. Reason:
Not Found
Powered by Jetty://
If I run this URL http://my-ip:3000 then it shows me
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
Powered by Jetty:// Java Web Server
I checked Jetty and it is running fine.
Now I'm confused whats not running. I'm new to Solr. Please help me?
Solr page is now opening on this URL http://my-ip:3000/solr
And showing me 4.4
I killed java process then it starts working
You may need going to the Solr directory: cd solr-6.2.0/ and launching it: bin/solr start The Solr admin UI will run on the port 8983 by default: http://localhost:8983/solr/. However, the support for deploying Solr 5.0 and newer on Jetty is unsuported, so you might consider another solution, without Jetty.
We are getting the following exception when a Java EE server tries to resolve a host name from one of the services. We were able to resolve that host name on the box manually with ping/nslookup command. We were also able to fire that external service using curl with same parameters what server is trying to use. So it seems like this issue happens only when we try to make a request to a external host from a Java/Java EE application.
To resolve this issue, we manually added an entry in /etc/hosts file and it solved the problem but we want a permanent solution so we don't have to keep changing the IP. It was working before without adding that entry but all of a sudden it stopped working.
Detail of our environment:
OS: Cent OS 6.3
Java : JDK 1.6.0_24
Java EE Server : JBoss AS 7.1.1
Http Client library : httpclient-4.0.jar
Thanks in advance for the help!!
Error while checking salesforce license|:
java.net.UnknownHostException: na15.salesforce.com at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
[rt.jar:1.6.0_24] at
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
[rt.jar:1.6.0_24] at java.net.Socket.connect(Socket.java:546)
[rt.jar:1.6.0_24] at
sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:584)
[jsse.jar:1.6.0_24] at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:333)
[httpclient-4.0.jar:4.0] at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
[httpclient-4.0.jar:4.0] at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
[httpclient-4.0.jar:4.0] at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
[httpclient-4.0.jar:4.0] at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
[httpclient-4.0.jar:4.0] at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
[httpclient-4.0.jar:4.0] at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
[httpclient-4.0.jar:4.0]
This is most likely a network management, change / configuration management or general system administration problem rather than a programming problem.
It was working before without adding that entry but all of a sudden it stopped working.
One approach is to try to figure out what changed to cause it to stop working. This is not the kind of thing that would happen spontaneously. Someone or something has changed some software or configurations to make this happen. Start with when it stopped (or when you noticed) and work back through your change logs.
It sounds like it is an issue with the Java DNS resolution procedure. It appears that the resolver is either not trying to talk to the normal DNS servers, or it is trying and failing.
We can't debug it for you, but I found these resources that help to explain what should be happening when you do a name lookup in Java, and offer some ideas on trouble-shooting.
Resources:
DNS and Java
Java doesn't pick up system's DNS settings change until restarted
Java and /etc/resolv.conf DNS server failover
Java networking properties
I found that these same symptoms can happen when IPv6 is disabled on your networking. You can see this by running a simple Java program:
import java.net.InetAddress;
public class NameTest
{
public static void main(String[] args) throws Exception
{
System.out.println(InetAddress.getByName("google.com"));
}
}
If IPv6 is an issue, then running the program with java -cp . NameTest will fail with a line like "at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)" in the stack trace (notice the Inet6 in the class name), and running the program with java -cp . -Djava.net.preferIPv4Stack=true NameTest will succeed (this is from the above answer Java networking properties reference).
To work past this, I followed suggestions from this question.
An OS-wide disabling of IPv6 works well, as the system doesn't have IPv6. On some Linux varieties, this can be disabled by first adding this line to the end of the file /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
followed by running sudo sysctl -p to immediately disable IPv6.
I am trying to connect to Mercury mail server with a java application and I am using JavaMail api. The connection is not successful and I’m getting this error in the log:
EHLO x.x.x.x
554 Invalid HELO format
Which means that it connects to the server but the helo format is not something that sever likes. I've tired to debug it and I got to this code in JavaMail “SMTPTransport” class which says:
serverOutput.write(cmdBytes);
serverOutput.write(CRLF);
serverOutput.flush();
and according to code:
private static final byte[] CRLF = { (byte)'\r', (byte)'\n' };
which seems consistent with RFC 821
I know that on windows \n has different meaning but I am not sure if this really is the root of problem? If it not then what can cause this?
I checked mail server with mail client and it works fine and I checked the code with James mails server and it also works fine!
JavaMail API version is: 1.4.5 (latest release)
Mercury/32 : 4.7
I did a Google search on 554 Invalid HELO format and got a ton of hits about your specific Mercury problem. It's a bug.
http://community.pmail.com/forums/thread/4136.aspx
http://www.mantisbt.org/bugs/view.php?id=9645
http://ellislab.com/codeigniter/forums/viewthread/153130/
etc...
You might need to check the logs on the server to figure out what it's really complaining about, but... One thing you can try is setting the mail.stmp.localhost property to the correct DNS host name for your machine. From the debug output it looks like your machine is unable to determine its own name and so is sending the IP address instead.
For me in a web project the PHPMailer() class was forcing Auth. Changing the Auth to false fixed it. Maybe check similar option for setting Auth to false in your language.
This is what I changed in my PHP code from true to false and adding sendmail_from in the php.ini file
$mail = new PHPMailer();
$mail->SMTPAuth = false;
I'm running an osgi-application locally in Eclipse. When I did it using windows it worked fine, it'a server/client setup.
I later installed Fedora 17 and tried doing the same thing, the server seems to be working fine but when I try to connect using the client I get the following error:
java.security.cert.certpathvalidatorexception no subject alternative dns name matching localhost found
I have tried googling the problem but I didn't find any silver bullets.
Has anyone got any ideas?