I'm running Wildfly version 14 and version 18 (on different machines) and Primefaces. Whenever I upload a file, I get 2 orphaned fds. I've doubled checked my code and all resources are closed. I didn't have any problem running Wildfly 11, btw. I also use lsof to make sure that the opened files belong to Wildfly, and they are. Eventually, I get the Too Many Open Files error.
ls -alFtr /proc/30724/fd|grep elete
lr-x------ 1 ora ora 64 Apr 3 09:36 594 -> /PATH_TO/undertow1607766259253292434upload (deleted)
lr-x------ 1 ora ora 64 Apr 3 09:40 591 -> /PATH_TO/undertow1607766259253292434upload (deleted)
Googling the problem gave me several RedHat links, but I can't find any solution to my problem. Any ideas?
Yes if you are using PF 7.X this was a bug and fixed in PF8.0.
See: https://github.com/primefaces/primefaces/issues/5408
Related
I have run into an interesting problem. I am compiling my application code and was using ace library(version 6_1_1) on my centos 6 machine. Everything worked fine. When i look at the symbols of the ace library compiled on centos 6 machine, it looks like this:
bash-4.1$ nm ace/libACE.so.6.1.1 | grep handle_sig 000f9430 T
_ZN15ACE_Sig_Adapter13handle_signalEiP7siginfoP8ucontext 000b84d0 T _ZN17ACE_Event_Handler13handle_signalEiP7siginfoP8ucontext 00079f10 T _ZN18ACE_Service_Config13handle_signalEiP7siginfoP8ucontext 000f26d0 T _ZN19ACE_Process_Manager13handle_signalEiP7siginfoP8ucontext 0007ee70 T _ZN19ACE_Service_Manager13handle_signalEiP7siginfoP8ucontext
000cf920 T
_ZN20ACE_MMAP_Memory_Pool13handle_signalEiP7siginfoP8ucontext 000f8b80 T _ZN22ACE_Shared_Memory_Pool13handle_signalEiP7siginfoP8ucontext
bash-4.1$
But when i compile the same project on centos 7 machine, the symbols change:
bash# nm ace/6_1_1/ace/libACE.so.6.1.1 | grep handle_sig 000fa090 T
_ZN15ACE_Sig_Adapter13handle_signalEiP9siginfo_tP8ucontext 000b9570 T
_ZN17ACE_Event_Handler13handle_signalEiP9siginfo_tP8ucontext 0007e070 T
_ZN18ACE_Service_Config13handle_signalEiP9siginfo_tP8ucontext 000f3500 T
_ZN19ACE_Process_Manager13handle_signalEiP9siginfo_tP8ucontext 00081cb0 T
_ZN19ACE_Service_Manager13handle_signalEiP9siginfo_tP8ucontext 000d1990 T
_ZN20ACE_MMAP_Memory_Pool13handle_signalEiP9siginfo_tP8ucontext 000f93d0 T
_ZN22ACE_Shared_Memory_Pool13handle_signalEiP9siginfo_tP8ucontext bash#
Notice that there is an extra _t in siginfo. So, my application which links this library fails to launch during run time giving me that error:
symbol "_ZN17ACE_Event_Handler13handle_signalEiP9siginfo_tP8ucontext"
not found
Another interesting point to note is that if i copy the compiled ace library from my centos 6 box into centos 7 box, my application works fine.
I am lost on how to fix this issue. Any help in this regards will be appreciated!
But when i compile the same project on centos 7 machine, the symbols change:
Probably Glibc on Centos 7 has changed one of the types in public headers which caused mangler to emit different symbols:
$ echo _ZN15ACE_Sig_Adapter13handle_signalEiP7siginfoP8ucontext | c++filt
ACE_Sig_Adapter::handle_signal(int, siginfo*, ucontext*)
$ echo _ZN15ACE_Sig_Adapter13handle_signalEiP9siginfo_tP8ucontext | c++filt
ACE_Sig_Adapter::handle_signal(int, siginfo_t*, ucontext*)
Notice that new method now uses siginfo_t rather than siginfo (you'll see hundreds of complaints if you google for "siginfo_t vs siginfo").
Another interesting point to note is that if i copy the compiled ace
library from my centos 6 box into centos 7 box, my application works fine.
That's backward compatibility - you can (usually) run apps linked on older version of distro on it's newer versions.
On the contrary, forward compatibility (in your case - linking old application against new library) is not guaranteed.
I am lost on how to fix this issue.
If you are only interested in new CentOS - rebuild all your code. If you want to run on older versions - build on the oldest and distribute that.
I'm trying to use JetS3 to access Amazon S3 in an app which also uses Jersey with Grizzly (unsure if that is relevant). My dev environment is Eclipse on OSX 10.7.3 using JRE version 1.7.0u.jdk.
I've read that it relates to not being able to find a "keystore", whatever that is - but it shouldn't need to use any local keys, I'm already providing it with the authentication information for S3 programmatically.
I don't know if this is an issue with my code, or with my dev environment, can anyone help?
edit: I added the following on the command line:
- Djavax.net.ssl.keyStore=/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home/jre/lib/security/cacerts
This file exists, but I'm still seeing the same error :-(
The intersection of Java's file tree and Apple's packaging system strikes again!
I just solved something similar to this (I think the legacy of a botched beta upgrade). Same error, at least. The situation I found on my disk was that there were symbolic links in my JDK installation instead of actual files (including cacerts):
> ls -lt /Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Home/lib/security/
total 24
lrwxr-xr-x 1 root admin 79 Apr 7 15:11 blacklist -> /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist
lrwxr-xr-x 1 root admin 81 Apr 7 15:11 cacerts -> /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
lrwxr-xr-x 1 root admin 87 Apr 7 15:11 trusted.libraries -> /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries
Unfortunately the linked Deploy.bundles did not exist.
In my case, I was able to look back in Time Machine, and find the deleted bundles and restore them.
You may have some older versions already in place that you could link to. At the least you should be able to look and see if you've got a similar underlying issue.
Sorry it's not a complete solution, but I hope it gets you a little farther down the road.
You could always just get the distribution from Oracle, and pop the cert files in place, though if your installation is missing other items there might be other problems.
On google I found this blog:
http://architecturalatrocities.com/post/19073788679/fixing-the-trustanchors-problem-when-running-openjdk-7
The problem there is the openjdk not including the files, and he recommends linking to the Bundle file that I had to restore in my case.
I am having a weird issue with Solr. I am using Rails 3 with Sunspot gem and everything was fine when I was running off my local instance of Solr. But once I tried running same code in a different environment with more data (10M records or so as opposed to 20K in local environment) and remote Solr instance, Solr started throwing errors like this when I run rake sunspor:reindex:
Solr Response: Internal Server Error
And tomcat6 logs would contain an error like this:
Jul 5, 2011 10:14:29 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr4 path=/update params={wt=ruby} status=0 QTime=6
Jul 5, 2011 10:14:30 AM org.apache.solr.update.processor.LogUpdateProcessor finish
INFO: {add=[Project 395767, Project 396057, Project 396078, Project 396139, Project 396368, Project 396409, Project 396421, Project 396442, ... (8 added)]} 0 73
Jul 5, 2011 10:14:30 AM org.apache.solr.common.SolrException log
SEVERE: java.io.FileNotFoundException: /opt/solr/solr4/data/index/_0.fnm (No such file or directory)
It seems happening at random times (not the same project causes it).
I tried deleting Solr index folder and rebuilding index from scratch. That didn't have any effect except that Solr started complaining about different .fnm file.
Same error happens if I'm building my models in Rails. I was populating the database from .csv file and Sunspot would choke at random records
Solr Response: Internal Server Error
with the same missing .fnm file error on Solr server.
Did anyone experience anything like that? Any ideas at all would be welcome!
I think I have figured it out on my own. Problem was caused by incorrect Solr configuration. There were two Solr instances pointing to the same index directory.
A source file that the application requires, is missing.
It is possible that you didn't upload your application files correctly. Please check whether all your application files are uploaded.
A required library may not installed. Please install all libraries that this application requires.
Further information about the error may have been written to the application's log file. Please check it in order to analyse the problem.
Error message:
no such file to load -- bundler/setup
Exception class:
LoadError
Application root:
/srv/www/thecampusblitz.com/TheCampusBlitz/current
Backtrace:
File Line Location
0 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 in gem_original_require'
1 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 inrequire'
2 /srv/www/thecampusblitz.com/TheCampusBlitz/releases/20110326070845/config/boot.rb 6
3 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 in gem_original_require'
4 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 inrequire'
5 /srv/www/thecampusblitz.com/TheCampusBlitz/releases/20110326070845/config/application.rb 1
6 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 in gem_original_require'
7 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 inrequire'
8 /srv/www/thecampusblitz.com/TheCampusBlitz/releases/20110326070845/config/environment.rb 2
9 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 in gem_original_require'
10 /usr/lib/ruby/1.8/rubygems/custom_require.rb 31 inrequire'
11 config.ru 3
12 /usr/lib/ruby/1.8/rack/builder.rb 46 in instance_eval'
13 /usr/lib/ruby/1.8/rack/builder.rb 46 ininitialize'
14 config.ru 1 in `new'
15 config.ru
was working a week ago when i nuked my server any ideas?
bundler runs fine all gems installed.
rake runs fine,able to run migrations,console and database connectivity
This is the key to your error: no such file to load -- bundler/setup That suggests that Bundler is not installed on the server.
You say that bundler runs fine, not sure whether you mean that it runs from the console on the server - but it's not running for your passenger. So perhaps your passenger settings are pointing to a different Ruby installation, and bundler is not setup for that.
I'd start there.
I noticed the same error. Turns out it's a byproduct of using rvm. If you're using rvm, forgetting to set the gemset will result in this error. hth.
I also noticed that one of the major problem was the file permissions on linux.
My user account didn't had enough privileges and passenger needs the app user account to have read/write privileges.
So permissions was the major problem apart from the other problems that these guys mentioned.
Those were present in my earlier installation.
I am running windows 2003 server. I had no problems doing a dw_1.saveas for a pdf until about 2 weeks ago when the hosting company decided to do a software update on the server. Now when I do a save as the file size is 0 kb. Any ideas?
I was also getting 0 byte files, running PB Classic 12.5.1 build 4541 on Windows 7 Enterprise SP1 64 bit. Based on the comments of both previous answers, I installed 32 bit Ghostscript 9.1 to default location, verified that the registry entry was not there, then installed 64 bit Ghostscript 9.1 to default location, saw the registry values were there, then modified the registry to point to the 32 bit installation directory as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript]
[HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.10]
"GS_DLL"="C:\\Program Files (x86)\\gs\\gs9.10\\bin\\gsdll32.dll"
"GS_LIB"="C:\\Program Files (x86)\\gs\\gs9.10\\bin;C:\\Program Files (x86)\\gs\\gs9.10\\lib;C:\\Program Files (x86)\\gs\\gs9.10\\fonts"
Save As PDF using Distill is now working.
Edit 2: Another cause I've seen is mis-matched PowerBuilder DLLs and PBDs. Make sure that the runtime DLLs and PBDs on the server are the same as the ones on the machine where the app was built.
Edit: I re-read your question. A zero byte PDF usually indicates that PowerBuilder couldn't find GhostScript. Check the registry as described below, and check the folder GhostScript is installed in. Re-running the GhostScript installer should fix it. I'll leave the rest of the troubleshooting info in case anyone else needs it.
If you're using Distill, the problem could be that the server configuration was changed to require signed drivers. If so, you'll have to install the "Sybase DataWindow PS" printer with a signed driver. I find the 'HP 8150 Series PS' driver works pretty well. I wrote up directions in Saving a datawindow as PDF in PB 10.5.
You might get a useful error message if you try to print to Sybase DataWindow PS from Notepad. Another possibility is that the Registry entries that PowerBuilder uses to find GhostScript got clobbered. We had that on a couple of workstations. Here's what I have for Ghostscript 8.60 (The GhostScript installer creates these entries):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript]
[HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.60]
"GS_DLL"="C:\\Program Files\\gs\\gs8.60\\bin\\gsdll32.dll"
"GS_LIB"="C:\\Program Files\\gs\\gs8.60\\lib;C:\\Program Files\\gs\\fonts;C:\\Program Files\\gs\\gs8.60\\Resource"
I used Process Explorer to troubleshoot problems with PowerBuilder's Save as PDF functionality.
I had the same problem (PDF with 0 KB size) when I use Windows 2003 Server 64 bits and I resolve my problem like shown here :
=> At first, when I install Ghostscript 32 bits version, I see no entries in the Registry.
=> When I install a Ghostscript 64 bits version, there is no problem in the Registry, entries are created, but the system doesn't work (PDF is generated with 0 KB size)
=> I create a new directory with Ghosscript 32 bits version and I change the Registy entries
=> And then I uninstall the 64 bits version.
=> AND NOW, EVERYTHING IS OK !
Used Ghostscipt versions : gs904 for the 32 bits version and gs910 for the 64 bits one.