Jump to content
We've recently updated our Privacy Statement, available here ×

theodan

Members
 View Profile  See their activity

  • Posts

    19

  • Joined

  • Last visited

 Content Type 

Profiles

Forum

Events

Featured Visualizations

Knowledge Base

Documentation (PDF Downloads)

Blog

Documentation (Test Area)

Documentation

Dr. Jaspersoft Webinar Series

Downloads

Everything posted by theodan

  1. theodan
    Thanks, Lucian. That works for the most part, except it still leaves the "Report Options" image and the five "Export to xxx" images in the upper left. Is there any way to suppress those as well? We have our own front-end which already has input controls and options for the output format. Thanks again, -Dan
  2. theodan
    In JS 2.1, we used a URL like this: http://<server>/jasperaccess/generateReport?uri=/reports/myReport1&myParam1=foo&format=html to execute a report via HTTP. The output would be formatted as HTML and would be "standalone", meaning without the JasperSoft header, Home/Logout bar, etc. In JS 3.5, we use a URL like this: http://<server>/jasperserver/flow.html?_flowId=viewReportFlow&reportUnit=/reports/myReport1&myParam1=foo&output=html but we get stuck with the JasperSoft header, Home/Logout bar, etc., in the output. What's more, this only happens when output=html. Is there any way in JS 3.5 to suppress the JasperServer decorations and get the same "standalone" HTML output we were getting in JS 2.1? Thanks, -Dan Post Edited by theodan at 12/31/2009 22:01
  3. theodan
    Sorry for the bad formatting originally. Hopefully now this is easier to read.
  4. theodan
    Hello. We're using JasperServer 2.1 and 3.5 in different environments. We have a front-end webapp that runs reports for its users via the Repository HTTP API. I noticed that when there is a back-end error (SQLException, etc.), at least in JasperServer 2.1 the HTML returned to the user contains no error message whatsoever: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=windows-1252" http-equiv=Content-Type></HEAD> <BODY></BODY></HTML> I would at least expect the user to see a simple "Unexpected system error" message. The fact that the response is blank is driving our users nuts when there's a problem. And this is very different from the extremely detailed error page you get when you run a report via the JasperServer front-end itself. Is the error page at all customizable? Further, is it possible to specify different error messages for different exception types? And has anything about this changed in 3.5? Thanks, -Dan Post Edited by theodan at 09/27/2009 18:59
  5. theodan
    Hello. I have a parameter that I use in my report query to supply part of the SQL itself (using $P! syntax). The problem I'm seeing is that everything works fine when the <queryString> is defined within the JRXML, but when I move the query into the repository and set my report unit to use it, this same parameter gets substituted into the SQL as "null" at report runtime. I found some past forum topics suggesting there were some issues with parameters in queries becoming null when the queries were moved from the JRXML to the repo, but I haven't yet seen a definitive explanation of what the problem/bug and workaround are. My JRXML: <parameter name="idList" isForPrompting="true" class="java.lang.String"> <defaultValueExpression ><![CDATA[""]]></defaultValueExpression> </parameter> <parameter name="includeArchived" isForPrompting="true" class="java.lang.Boolean"> <defaultValueExpression ><![CDATA[boolean.TRUE]]></defaultValueExpression> </parameter> <parameter name="sqlIncludeArchived" isForPrompting="false" class="java.lang.String"> <defaultValueExpression ><![CDATA[$P{includeArchived}.booleanValue() ? "" : "and ARCHIVE_DATE is null"]]></defaultValueExpression> </parameter> My query: select * from T where ID in ($P!{idList}) $P!{sqlIncludeArchived} The weird thing is that idList works just fine. It's just sqlIncludeArchived that becomes null. I'm running the report via "/jasperaccess/generateReport", so I don't think input controls have anything to do with this. Just for kicks, I tried defining an input control for includeArchived, but that had no effect. idList already had an input control defined. We are running both JasperServer 2.1 and 3.5, and the problem exists in both. Currently my only workaround is to move the query back into the JRXML, but this will make repository maintenance a nightmare, because this issue is affecting a lot of report units that share the same query. Any help would be greatly appreciated. Thanks, -Dan Post Edited by theodan at 09/27/2009 18:23
  6. theodan
    I got almost the same exact error. Someone from the Jasper team, please look into this. In my case at least, it seems that the repo has become corrupt. I scheduled a large number of reports (about 1000 or so) a while back, and they ran up to a certain point, and the repo seems to have gotten corrupted by one of the generated ContentFiles. I say it's corrupt because when I export my repo ("--everything"), I get errors as soon as it hits that corrupt ContentFile. The errors I'm seeing from js-export are very similar to what the user above posted. This corrupting of the repo is a repeatable bug, in that my repo gets corrupted at the same exact point if I reschedule the large set of jobs and let them run again. I'm attaching the output of my js-export, as well as the error I get from the front-end when I try to delete the ContentFiles subfolder that contains the corrupted item(s). Thanks in advance, -Dan Post Edited by theodan at 07/02/2009 20:32
  7. theodan
    Thanks Bhavya. I had figured that out, but it seems like a less than ideal solution. Right now my reporting run takes around 20 minutes. As I schedule more reports in the next few days, it will take a couple of hours. Eventually, it will take 10+ hours, and then several days. I shouldn't have to keep increasing "org.quartz.jobStore.misfireThreshold" as my runs get longer over time. There should be a setting like "-1" to tell Quartz or JS to always handle "misfired" jobs. Better yet, JasperServer's MisfireHandler should give us the option to have it actually execute misfired jobs, rather than just logging them in DEBUG mode. Sometimes you don't care that a job is "misfired", and you just want all jobs to be executed, even if it means Quartz may fall behind (because, for example, you know your load is such that this can never happen in reality). -Dan
  8. theodan
    Post Edited by theodan at 05/31/2009 23:19
  9. theodan
    I know "it is what it is". That was my point. : ) Using Google with a "site:jasperforge.org/plugins/espforum" term can help sometimes, but it doesn't show the title of each thread in the results, instead displaying "JasperForge: JasperServer Project Forums" for all of them. Also, the results themselves are not reliable. I search for "misfire" on your forum, and I get 10 results. With Google I get 0. The bottom line is that open-source technologies are at least half made by their communities. You guys are busy developing, so the documentation can't be completely thorough. The "Ultimate" guides (we've bought 2 of them) are fairly basic, and are of almost no help when you're running into bugs, etc. The best source of info in these scenarios is your forums. And the fact that Fireboard's search is absolutely pathetic takes away a lot of power from your community. Please consider upgrading your forums to a better software package, and please treat search as the most important feature when deciding on one. Right now it's like we're driving a Ferrari that can only go 20 mph. Thanks for reading, -Dan
  10. theodan
    My JRXML has two java.util.Date params. JasperServer (or JasperReports) was adding a timezone offset to them, even though they already had timezone offsets applied to them. For example, 5/31/2009 00:00:00 CDT was becoming 5/30/2009 19:00:00 CDT when I printed the param in the JRXML using a <textFieldExpression>. I'm not sure if it was actually changing the underlying Date param object, or if it was just doing this when displaying its value. I was also using the param in my <queryString>, and I haven't done extensive testing to see if the query was using the correct or incorrect value. This was happening in all of my JRXML's except one. It took me a while to figure out why that one handled the Date params correctly, but I finally realized it was because it had: <queryString language="SQL"> instead of: <queryString> as the others did. So I'm not sure if this qualifies as a bug, and I didn't do extensive testing to see what happens when query languages other than SQL are specified. But I figured I should let someone know about it. -Dan Post Edited by theodan at 05/31/2009 17:04
  11. theodan
    I cannot find this feature request in Tracker. Sounds like "artf2152" was from an older Tracker db? Anyway, was this ever implemented? I'd actually prefer that no Content File and no e-mail would get generated when the report query returns an empty result set. Thanks, -Dan
  12. theodan
    Turns out it's org.quartz.jobStore.misfireThreshold that fixed my problem. I modified js.quartz.base.properties as follows: org.quartz.jobStore.misfireThreshold=36000000 Now all 1000 of my reporting jobs run to completion. However, this fix doesn't seem ideal. I shouldn't have to keep increasing this setting to keep up with however long each reporting run will be expected to take. There should be a way for me to tell JS/Quartz that I want all jobs to run, regardless of how late they are. What was basically happening before I put in the fix was that org.quartz.jobStore.misfireThreshold was set to the default value of 180000 (3 minutes). So JS/Quartz were processing as many of my reports as they could in the first 3 minutes, after which all the rest of them were being declared "misfires". Unfortunately, the "MisfireHandler" kept saying it was "handling" the misfires, but it wouldn't actually invoke the misfired jobs or do anything else with them except log them as misfires. I've attached a small part of the DEBUG-level log file that shows this problem. Is the MisfireHandler a JS component or is it a Quartz component? Does something have to be configured to tell JS/Quartz to "always run misfired jobs no matter how late they are"? Post Edited by theodan at 05/30/2009 21:12
  13. theodan
    The "Advanced Search" is not very advanced at all. A forum for developers that doesn't support features like phrases, boolean searches, boosting, proximity searches, fuzzy searches, etc., is pretty useless. Also, an Advanced Search screen should have a "Search Tips" link telling the user which search features it supports and how to use them. Please look into using Jive Forums (check out Quartz Scheduler's forums as an example) or some other mature forum technology that supports these basic features. Otherwise, users: 1. won't be able to find answers to their questions 2. will get very frustrated and their opinion of your product will suffer 3. will keep asking the same questions over and over, thus taking away development time from your developers that could be better spent working on the product Thanks, -Dan Post Edited by theodan at 05/30/2009 20:52
  14. theodan
    This thread: jasperforge.org/plugins/espforum/view.php seemed promising, but either I followed its advice incorrectly or it just doesn't work. I tried modifying js.quartz.base.properties (not js.quartz.properties, like the thread suggested, because that didn't seem like the right file) by adding: org.quartz.scheduler.idleWaitTime = 600000 but not only did that not improve anything, it doesn't really make sense after researching it. The Quartz wiki docs define this setting as "the amount of time in milliseconds that the scheduler will wait before re-queries for available triggers when the scheduler is otherwise idle". In other words, it's the scheduler's trigger polling interval. From my understanding, that has nothing to do with how long triggers are considered valid, as suggested in that other thread. Post Edited by theodan at 05/30/2009 15:15
  15. theodan
    pariz Wrote: Hi Marco, the problem is the time-window that triggers are considered valid. That's the parameter : org.quartz.scheduler.idleWaitTime The default time is set to 30000ms. I advice to add it into js.quartz.properties with a time at least of 600.000ms (10 minutes). Code: Then you change it for your needs. For a deeper description of this parameter and others look here ;) Post edited by: pariz, at: 2008/01/30 14:21 Did you mean "add it into js.quartz.base.properties"? And did you mean your code to read: org.quartz.scheduler.idleWaitTime = 600000 ? Also, what made you interpret org.quartz.scheduler.idleWaitTime as representing "the time-window that triggers are considered valid"? From the Quartz wiki docs, this setting is defined as "the amount of time in milliseconds that the scheduler will wait before re-queries for available triggers when the scheduler is otherwise idle". In other words, it's the scheduler's trigger polling interval. From my understanding, that has nothing to do with how long triggers are considered valid. I was really encouraged by this thread, as it seemed to promise a solution to my own problem, which is detailed here: jasperforge.org/plugins/espforum/view.php but I'm more confused now than before. I tried making the 2 changes suggested in this thread (in js.quartz.base.properties, not in js.quartz.properties), but neither change seemed to help my situation. My jobs still stop running after about 3 minutes, leaving most of the 1000 scheduled jobs as never having run. Post Edited by theodan at 05/30/2009 15:23
  16. theodan
    I have found several other JS forum posts suggesting I'm not the only one with this problem. They suggest that whenever you schedule more than 25 or 50 reports to run at the same time, many of them simply fail to run, with no exception in the logs and no clue as to what happened. I turned on DEBUG logging and read up on Quartz Scheduler and got some further ideas. Given that: - I scheduled 1000 report jobs to run at the same time - My report queries can take up to 1 minute each to run - I'm using the default Quartz thread pool size of 2 it seems that a lot of the triggers in Quartz are "misfiring", and this is to be expected. According to Quartz docs, a "misfire" is what happens when the time for a trigger passes and no Quartz thread is available to process that trigger. Quartz has a MisfireHandler that is supposed to scan persistent triggers for misfires, and process them as soon as threads are available. I innocently assumed I didn't have to worry about any of this, and that somewhere between Quartz and JS, someone would make sure that all misfires would eventually be picked up and processed correctly. I have no problem with reports missing their scheduled time, as long as they do actually run eventually. But I kept an eye on my database machine, and its CPU usage goes from 90% to 0% about 3 minutes after my 1000 reports were scheduled to run. So basically JS/Quartz runs about 50 of the 1000 scheduled reports, and then seems to just give up on the other 950. I'm not sure if the bug is in Quartz or in the way JS has configured Quartz. Given that Quartz does nothing but scheduling and has been stress tested in enterprise apps for a long time now, I'd put my money on the latter. If anyone has any ideas to focus my needle in a haystack search, they'd be very much appreciated. Thanks, -Dan Post Edited by theodan at 05/30/2009 14:50
  17. theodan
    Was any solution ever found for this? It seems related to my issue as well: jasperforge.org/plugins/espforum/view.php It seems that something in the way JS configured Quartz makes it unable to handle anything more than a few (i.e. less than 50 or so) scheduled reports that are supposed to run at the same time. -Dan
  18. theodan
    Yes, I'm experiencing the same problem whereby some but not all scheduled reports run. I've posted it as a separate thread here: jasperforge.org/plugins/espforum/view.php -Dan
  19. theodan
    Hello. I have 5 report units in my repository. I scheduled about 1000 jobs (total) for them via web services, all set to run at the same time (12:50). My report queries can each take up to 60 seconds to run. Some of the jobs did seem to kick off at the expected time. All 1000 jobs had their "Next run time" updated, as expected. However, only about 80 of them actually seemed to run (i.e. generated outputs) or had their "Last ran at" timestamp updated. The other 920 never seemed to actually run and had empty "Last ran at" timestamps. I'm using JS 3.5, and have not modified any of the default Quartz settings or properties. No exceptions were logged by either JS or Quartz. The only curious entries I found were the last ones: 12:50:07,099 WARN FileBufferedOutputStream,Finalizer:240 - Error while deleting the temporary file 12:50:07,099 WARN FileBufferedOutputStream,Finalizer:240 - Error while deleting the temporary file 12:50:16,114 WARN FileBufferedOutputStream,Finalizer:240 - Error while deleting the temporary file 12:50:57,083 WARN FileBufferedOutputStream,Finalizer:240 - Error while deleting the temporary file 13:24:31,645 WARN FileBufferedOutputStream,Finalizer:240 - Error while deleting the temporary file but I'm still not convinced these are at all related to my problem. I've tried this entire experiment about 5 times now, and each time roughly the same thing happens. The exact number of jobs that actually run varies, but it's never been above 50-100. Any ideas? Thanks, -Dan Post Edited by theodan at 05/30/2009 15:20
×
×
  • Create New...

© 2024 Cloud Software Group,
Inc. All rights reserved.

Products

Explore