Charith, I am happy to report that your solution has worked. Thank you for your assistance.
I have made the change to the JVM in my test system - (-Djava.awt.headless=true). I am monitoring it’s affect and will provide further information.
This is a duplicate. The same error was reported in the community:
Unless I am not understanding correctly you say the File Path is “MIGRATION”. Yet in the file configuration screen, where you are picking the file, the path is “ASSET”. In order for the job to work, the file must be on “MIGRATION”.
I too experienced this issue. Even IFS was not sure why I was getting it. Here is what resolved it.IFS kept saying it could not connect to the host. What was really happening is that it could not write to the host based on the format defined in the address data. Take note of the sequence of the address data that is now working. The file name is first, and then the directory. I thought it should have been the other way around. Also, I had been adding a slash / at the end of the file directory, which was also incorrect.I hope this helps others.
2 years later and this problem still persists. I get the same message when I use the address tester. I’ve done everything that has been described in this thread but cannot get an SFTP sender to work.
Charith,Thank you for your reply. I have been fighting this issue on/off for a couple of years. I have been restarting the middleware monthly. The funny thing is, the printer issues usually occurs a few days after the restart. At least that’s what it seems like. Once restarted it does not occur again for quite a while. The X11.XToolkit error did catch my eye, but I did not find your suggestion. I will give it a try on my test system which also can experience this error. It may be some time before I can report on the success or failure since I cannot force the error to occur.Doug
Let’s summarize.You have copied the PrintAgent zip file from your IFS installation to the server onto which you want to run the print Agent You have unzipped the file. You have created the print agent by following the instructions. Have you added your printers into the ifs-printagent-config.xmlEntries should be similar to this <PRINTER_MAPPINGS> <PRINTER_MAPPING> <LOGICAL>FLP_IT_OFFICE</LOGICAL> <PHYSICAL>FLP-IT-DEV1</PHYSICAL> </PRINTER_MAPPING> <PRINTER_MAPPING> <LOGICAL>TLL_FRONT_OFFICE_ACCOUNTING</LOGICAL> <PHYSICAL>TLI-PRINT-200</PHYSICAL> </PRINTER_MAPPING></PRINTER_MAPPINGS>You installed the print Agent service You started the print agent serviceYou may need to check the ifs-printagent-service-ifm to make sure it is pointing to the correct JAVA location. After doing all of this, are you still having problems?$SERVICE.CMD_LINE=C:\Program Files (x86)\Java\jre1.8.0_271\b
@MitDenukN I’m not sure what you mean by ‘setup servers’. Of course you need to install JAVA. Then just follow the installation instructions you have.
I’m sorry. I was asking because it can be defined as a user-only defined variable and it was not clear in your description.Did you use the PrintAgent.zip file from the IFS7.5 system you are trying to create the print agent for?Is this print agent being created on the same server as your other print agent?The documentation doesn’t mention it, but I have always installed the print agents using and admin user ID.
Is the JAVA_HOME variable defined in the System variables. example:
Baris,Our Oracle database is running on a Linux server. For document storage we have created an NFS mount point to a network file share server. We have defined a directory object in the database that uses a path on the NFS mount point.We had a problem where we lost access to the NFS mount point. When this happened, IFS continued to try to access it and did not time out. The JAVA process (thread) that initiated it became STUCK. As more and more threads became stuck, fewer were available to do work. Users began competing for the limited resources until things ground to a halt. We did not have a monitor that warned us of the dropped NFS mount. It was only after engaging our IT Operations group that they discovered the problem with the NFS mount. Once they restored the mount point the issue went away. I hope this helps.
Ultimately the problem with the invalid printer had to do with the configuration of the printer on the server where the print agent was running. We deleted and recreated the printer queue on the server and verified the name in the printagent_conf.xml. The issue is now resolved.
The stuck messages were caused by a problem with an NFS mount where we store our IFS-Docs. It repeatedly dropped and the java processes that were trying to access it became stuck. Unfortunately the stuck threads had not reported why they were stuck so it took a while to identify the root cause.
I found what I believe to be the cause of the problem. The formula used is based on the current systdate. Once the background job executes, it reschedules itself for the same time (16:15) on the current date. The background process checks and notices the newly scheduled job has not run for today and it reruns it, which causes it to reschedule again for today. On or after midnight of the last day of the month, when the job runs again, it schedules it for the last day of the next month. This stops it from running until then.The Solution:The formula that does not cause this problem is based on a sysdate in the future so it does not reschedule the job for ‘today’.last_day(trunc(add_months(SYSDATE,1))) +1-(ifsapp1.site_api.Get_Offset('site')-.25)/24
Hi Kanishka,I did locate my old cases under the Legacy G Cases - Thank you.Unfortunately I checked further regarding the IFS Application 8 instance. I can only locate that product when I open a case under “Service Partly Unavailable”. Otherwise It does not appear in the product drop down on any other screen.In many of the case screens, the product drop down is empty or only displays IFS Cloud. It never displays our IFS Application 7.5 instance.FYI: We have not actually started the upgrade to IFS Cloud yet.
Thank you Chanaka.I have defined the logical printers in the printagent_conf.xml and see the mappings in the log. Now I see a message that the printer name is invalid. That’s progress. I’ll try to figure out what is wrong with the mapping and update this thread. I will also check the link you provided for other clues.
This would be good information except the https://portal.ifsworld.com/portal/ no longer works. What happened to it?We now get: Http/1.1 Service Unavailable
I get this same error when trying to log onto the IFS application. My system is APPS8 SP1. I just refreshed my QA database with an export of my prod system. After doing a reconfigure and F1MAGE, with no errors, I cannot log onto the application due to this error.Any suggestions are welcome.
Check that the IFSPRINT user is not locked. Also check if the password for IFSPRINT has expired.
The Oracle documentation has these notes on the ORA-04031 error:ORA-04031: unable to allocate nn bytes of shared memoryCause: More shared memory is needed than was allocated in the shared pool.Action: If the shared pool is out of memory, either use the dbms_shared_pool package to pin large packages, reduce your use of shared memory, or increase the amount of available shared memory by increasing the value of the INIT.ORA parameters "shared_pool_reserved_size" and "shared_pool_size". If the large pool is out of memory, increase the INIT.ORA parameter "large_pool_size".The ORA-04031 error also happens when you are using automatic memory management (sga_max_size), and the memory specific is too small.
After restarting the IFS application, the problem did not resurface.
I am watching this closely. We experienced a similar issue with our IFS8 SP1on a Linux platform. I worked with IFS support but were unable to definitively resolve the issue. After increasing the logging level on the batchserver and performing a reconfigure along with a restart, the problem disappeared. I’m not sure what ‘fixed’ it. I have not performed a restart since, but due to a weblogic/java memory leak that builds over six weeks, I will be performing a restart in the next week. I hope the issue does not resurface.
I have experienced similar issues in other versions of IFS. The problem is a result of a hardcoded message buffer size in the API/package. It limits the total amount of data in all fields that can be included in the update/write of the record. You may need to have the API/package modified.
I have a similar situation. From what I have been told by IFS, it is caused by a memory leak problem with JBOSS. My solution has been to restart the IFS application during our monthly scheduled data center maintenance window.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
