Skip to main content
M
mikechy
Inspiring
August 20, 2014
Answered

SOLR Not working with JVM 51+ on CF9

  • August 20, 2014
  • 2 replies
  • 729 views

Has anyone ever been able to figure out how to get SOLR properly working again after a JVM upgrade of _51 or later? 

I've read from a few sources that it's due to the permissions being changed in _51 forward and have applied the following (and several other iterations) to the java.policy file and restarted CF but Solr still remains broken.

grant {

     ....

     permission java.net.SocketPermission "*", "connect,listen,accept,resolve";

}

Also tried:

  permission java.net.SocketPermission "localhost:8983", "connect,listen,accept,resolve";

  permission java.net.SocketPermission "localhost:1-", "connect,listen,accept,resolve";

This is a real problem as there are security issues fixed in the later JVM's and we need to upgrade.

Thanks

Mike

    This topic has been closed for replies.
    Correct answer mikechy

    Actually we are on CF9 and can’t quite follow this part:

    “go into Sandbox Security and click on the entry for CFIDE, then add "127.0.0.1" which enters as "connect,resolve".”

    Are you referring to the “Server/Ports” tab?

    Also, if you make a change to the neo-security file in the admin, won’t it over write your manual change in the future?

    Mike


    Here's what ultimately worked for us, on CF 9

    In the default configuration, the neo-security file (<coldfusion>/lib/neo-security.xml) for CF9.1 contain three declarations of socket permissions in the following order:

    Path: C:\ColdFusion9\wwwroot\WEB-INF\     Permissions: connect, resolve

    Path: C:\inetpub\wwwroot\CFIDE      Permissions: connect, resolve

    Path: /*    Permissions: connect, resolve

    Manually edit the file and change each of the permissions above to connect, listen, resolve, then restart Coldfusion.

    2 replies

    WolfShade
    WolfShade
    Legend
    August 29, 2014

    GOOD NEWS!!!  A co-worker has found the solution!!!  I updated my bugbase report with the solution, so be sure to check it out.

    Bug#3795112 - CF9/CF10 - Java Updates 7.51+ break Solr collections

    ^_^

    M
    mikechyAuthor
    Inspiring
    August 29, 2014

    Oh, great news!

    We’re going to implement this over the weekend. Send Adobe the bill for your time Thanks for the heads up!

    greenlogo_450px

    Mike Chytracek

    Managing Partner

    p. 312.239.0032

    c. 815.302.3507

    f. 866.839.7896

    Anit_Kumar
    Anit_Kumar
    Inspiring
    August 29, 2014

    Point noted WolfShade

    Thanks

    Anit Kumar

    WolfShade
    WolfShade
    Legend
    August 26, 2014

    I've been having the same issue, for a while.  Still no solution.

    Have you checked your Sandbox Security?  I've noticed that if the CFAdmin JVM is pointing to Java 7.55 AND Sandbox Security is on, the Solr collections are broken (cannot administer in CFAdmin, and errors when trying to search); but if I turn off Sandbox Security (even with JVM 7.55), the Solr collections work and administer just fine.

    Problem is - can't turn off Sandbox in production, NOR can we roll back to a pre-7.55 JVM.

    Any possible solutions greatly appreciated.

    V/r,

    ^_^

    M
    mikechyAuthor
    Inspiring
    August 26, 2014

    Oh that’s interesting. We are using Sandbox security mostly to exclude some dangerous CF Tags.

    We’ve been banging our heads on this for weeks as well. It’s surely a permissions issue and you’d think someone at Adobe would have been able to solve this by now. If we discover anything I’ll surely pass it along and I’d appreciate it if you’d do the same.

    Good luck!

    Mike

    WolfShade
    WolfShade
    Legend
    August 26, 2014

    Sure thing.  All I know, so far, is that Java "over-tightened" security (thanks to some Russian hackers) and severely limited socket permissions.  Ever since 7.51.  I've found articles on modifying /ColdFusion10/cfusion/jetty/jetty.lax, but nothing has worked.

    I filed a bugbase report (zero votes), that did get some input by a few people, but no fix, yet.  Charlie Arehart has also been giving some advice.  But, so far, no one else has had this experience (that I've seen).

    V/r,

    ^_^

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices