We Keep Coding

JMeter can't read custom search_paths directory

I want JMeter to find a jar in lib/ext/custom.
In my jmeter.properties:
search_paths=lib/ext/custom
When I run the test, I get this output:
2019-06-25 10:21:54,792 INFO o.a.j.JMeter: search_paths=lib/ext/custom
2019-06-25 10:21:54,792 WARN o.a.j.JMeter: Can't read lib/ext/custom
Does anyone have an idea why it wouldn't be able to read that directory? It has the same owner as all the other directories/files and has the same permissions as lib/ext itself.
I turned the root longer to DEBUG but received no extra information than the above log messages.

The answer was simple. It could not read the directory because it could not find it because the value I provided it wasn't correct.
search_paths=../lib/ext/custom
It needed that look back to correctly find it. Putting the full path also worked.

Fuseki server doesn't show datasets

I'm new to Tomcat, Fuseki and the Shiro.ini file, so forgive me for asking silly questions.
System:
MacMini ==> OS.X 10.13 (acts as dev-server)
Java ==> 8
Tomcat ==> 9.0.10
Workflow:
Via a Plist file, the Tomcat instance gets started on each boot of the server.
in /Users/username/tomcat/webapps I've put the fuseki.war file which got extracted successfully.
I inserted a custom made RDF-file, which gets loaded after reboots and served
(this is where the good things end)
Problem:
I can access the RDF file through: http://localhost:8080/fuseki, I can perform SPARQL-queries and everything else I need to get done. However, when connecting the dev-server to a PC and accessing it through it's IP: e.g.http://192.168.0.112:8080/fuseki; I end up seeing the server which has a green status, and the entire web-interface works except for the datasets. When I go to http://192.168.0.112:8080/fuseki/dataset and press 'query' (or any other button) it displays: "Please select a database"
**Cause:
I found this thread fuseki webinterface does not show datasets (SO), which lead me to investigate the shiro.ini file. As it turns out I don't have one.
I then searched for shiro.ini and found a reference in /Users/username/tomcat/webapps/fuseki/WEB-INF/web.xml:
<context-param>
<param-name>shiroConfigLocations</param-name>
<!-- Try a path in: FUSEKI_BASE, FUSEKI_HOME, war resource
If a "file:" then look there and there only.
-->
<param-value>shiro.ini</param-value>
</context-param>
This made me think that I'd need to put the shiro.ini file in my root folder (Users/username/tomcat/webapps/fuseki/shiro.ini) and not in (Users/username/tomcat/webapps/fuseki/run/shiro.ini). However neither work.
I also looked in a logfile: catalina.out, based from that it seems that the shiro.ini file gets loaded (or at least there are no indiciations that there's an error with it.)
Here's the relevant extract from that log:
[2018-07-31 09:18:54] Config INFO FUSEKI_HOME=unset
[2018-07-31 09:18:54] Config INFO FUSEKI_BASE=/etc/fuseki
[2018-07-31 09:18:54] Config INFO Shiro file: file:///etc/fuseki/shiro.ini
[2018-07-31 09:18:55] Config INFO Context path = /fuseki
[2018-07-31 09:18:55] Config INFO Configuration file: /etc/fuseki/config.ttl
I can't find however any folder etc/fuseki/? So what's up with this to start with?
Here is the shiro.ini file:
[users]
admin=passXXX #non-default
[main]
#localhost=org.apache.jena.fuseki.authz.LocalhostFilter
[roles]
[urls]
##control open to anyone
/$/status = anon
/$/ping = anon
##rest restricted to Localhost
## see above for localhost
#/$/** = localhost
/**=anon
I'm not sure what's going on at this point, so any pointers are more than welcome.

Turns out the issue had more to do with my unfamiliarity with the MAC OS, than with Tomcat or Fuseki.
The folder /etc/fuseki which was referenced in the catalina.out file is tightly locked and it's actual path is /private/etc/fuseki (though this doesn't seem to matter)
By default you can't enter the fuseki folder due to no rights at all. Even doing:
sudo cd /private/etc/fuseki
or
sudo cd /etc/fuseki
won't work. I needed to give myself read/write access to the folder via getinfo (though I think you could achieve this as well via chown.
Now I could view that folder's content, yet all files and folders in there had the same issue and required the same solution. So now I could customize the shiro.ini and configuration/rdf.ttl file.
If I do
sudo cd /private/etc/fuseki
or
sudo cd /etc/fuseki
now, then I can successfully view the content.

ERROR Could not register mbeans java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")

When starting for example Elasticsearch 5.5 :
main ERROR Could not register mbeans java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")

Workaround with Oracle Java 1.8.0_131 is to open file <jre>/lib/security/java.policy and add this line to grant section (i.e. between curly brackets):
permission javax.management.MBeanTrustPermission "register";
Why workaround? The upright solution would be to specify extra grant section which code exactly should get this permission.

got the same error and the answer is here java.security.AccessControlException when using Ant, but runs ok when invoking java from console
Append the grant section in java.policy file with
permission javax.management.MBeanTrustPermission "register";

I had this same issue when moving from a single instance to two instances locally.
I tried what Alice suggested above. Even re-installed Elasticsearch (5.5.0).
I also updated my Java to the latest one for Linux provided by Oracle.
Nothing was working. Then I discovered, that I couldn't just take the elasticsearch-5.5.0/config directory and rename it to elasticsearch-5.5.0/node1.
So... I had to leave that config directory in place and clone it to node1/node2.
EVEN if I configure path.config in the runtime args, ES still needs that base line config directory.
Hope this helps.

I faced same issue on Ubuntu-16.04 system.
Solution:
ElasticSeearch service is not allowed to run for "ROOT" user. That's why change the ownership of elasticsearch folder with below command:
go to Elasticseach installation directory
$ sudo chown -R user_name:user_Group elasticsearch-5.5.0
$/bin/elasticsearch
this will start elasticsearch service. It is working form me perfectly.

Streamsets Error - Bad File Descriptor

I was attempting to use Streamsets to query an Oracle database and publish the data into Kafka. I downloaded Streamsets' tarball on my Mac and unzipped it into my home directory. Running $HOME/streamsets-datacollector-2.1.0.2/bin/streamsets dc started up on my first try, then I followed the instructions here to add the jdbc driver, then the instructions here to configure my streamsets job. However, I got an error: JDBC_00 - Cannot connect to specified database: com.streamsets.pipeline.api.StageException: JDBC_06 - Failed to initialize connection pool: java.sql.SQLRecoverableException: IO Error: Bad file descriptor.

This wound up having something to do with the limit on the number of files a process can have open. When I ran ulimit -n on the laptop, it showed 4864, then I set it to 10,000 via ulimit -n 10000, restarted the streamsets server, and it worked! If I need to keep running this, I will find a more procedural way of setting the ulimit for this process to work around this issue.

you definitely want need increase ulimit -n. To permanently change for all users in Ubuntu try the following:
echo "* soft nofile 60000" > /etc/security/limits.d/*_limits.conf && echo "* hard nofile 60000" >> /etc/security/limits.d/*_limits.conf
substitute 60000 with whatever number you want. I've never had a problem in streamsets using 60k. you should be able to do something similar in bsd.

PWC1231 and PWC6344

I have two servers running on Glassfish 2.1 both have the same web app.
Two times this error occurred: Some jsp pages stop displaying only showing a blank page, and the following errors are printed in the logs...
PWC1231: Servlet.service() for servlet jsp threw exception
java.io.FileNotFoundException: /path/to/jsp/file/jsp_file.jsp.java
(Permission denied) at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179) at
java.io.FileOutputStream.(FileOutputStream.java:70) at
org.apache.jasper.compiler.AntJavaCompiler.getJavaWriter(AntJavaCompiler.java:213)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:173)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:409) at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:344)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:542)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:474)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:366)
at
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056)
at
org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261)
at
org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:388)
at
org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:316)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
com.my.app.filtro.FiltroCallcenter.doFilter(FiltroCallcenter.java:90)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at
com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Followed by this:
PWC6344: Unable to create output writer for file /path/to/jsp/file/jsp_file.jsp.java|#]
Sometimes only the PWC6344 error is printed and sometimes both, the PWC1231 error is always followed by PWC6344 (which somewhat makes sense, because that exception is thrown when an IOException occurs).
Well, both times this errors happened, the only thing I did was stop and start the instance, and everything was alright again, also this error has only occurred in one of the servers.
Whats is happening ?... Or how can I diagnose what is causing this so I can fix the problem instead of stopping and re starting for eternity...
UPDATES:
I was looking into the possibility of this been a file descriptor problem, as suggested by sbridges but!, the maximum number of file handlers is 811975 with 4520 opened files in one server and 359532 with only 6894 in the other.
So, I guess its safe to say this is not the problem!
Does someone have another theory?

It looks like the permissions are set incorrectly and you can't write the compiled jsp page to disk,
/path/to/jsp/file/jsp_file.jsp.java (Permission denied)
Are the permissions correct on that directory/file?

Rename jsp_file.jsp.java to jsp_file.jsp.

PWC6344: Unable to create output writer for file /path/to/jsp/file/jsp_file.jsp.java|#]
This can also happen if the underlying operating system has run out of file handlers/descriptors which are required in order to open a file for reading or writing. I'm not closely familiar with CentOS, but Google hints that it has a "relatively low" limit of 1024 given the lot of problems related to it in the search results. Among the results you'll see a lot of questions/answers as to how to increase it, such as the following blog:
Increase the number of file descriptors on Centos and Fedora Linux
Raising the number of file descriptors for a regular user on CentOS/Fedora/Redhat is surprisingly difficult to learn how to do. There are lots of incomplete walk throughs on the web, some with typos and other problems.
Here are the steps that worked for me to raise the open file descriptor limit from 1024 (the default) to 65535:
As root, edit /etc/sysctl.conf and add the line:
fs.file-max = 512000
At the bash prompt, run:
$ sysctl -p
That will cause the settings to take effect. You can also cat 512000 > /proc/sys/fs/file-max but that may reset on reboot.
Edit /etc/security/limits.conf and add the following:
* - nofile 65535
See the inline comments for more details on what that does and how to make it more restrictive if you prefer.
As root, run
$ ulimit -n 65535
and make sure you have no errors. To double check, run ulimit -n and make sure the response is 65535.
Ensure that PAM authentication is turned on for SSH, or else when you try to connect as a regular user, you won’t see the new limits. Edit /etc/ssh/sshd_config and make sure you have:
UsePAM yes
Restart SSH /sbin/service sshd restart if you made any changes.
Login as a regular user with a new SSH session & shell and run:
$ ulimit -n 65535
Run ulimit -n again to check and good luck!