Dataproc Zeppelin component hides the cell output after few minutes of starting while the spark job is still running and there is no way to show it again. It appears only after the cell processing ends. For the first few minutes the logs keep showing however it suddenly disappears saying outdated (which is not the case as the cell is still processing pyspark code). Has anyone encountered similar issue. Is there anything in the configuration that can be changed to fix this?
Related
We have a process that generates around 20,000 PDFs using SSRS as the backend.
The mechanism used to generate these is the Report Execution 2005 API endpoint
We have just performed a run where occasionally a PDF would be generated missing some data, or the header or the body or the footer.
The break down of that was around 12,000 generated correctly, 1000 blank, 7000 data incorrect.
There doesn't seem to be a rhyme or reason for this, no pattern in the data or timings. In the logs we can see the following:
We log all parameters used to execute these reports in a DB, so using this we went and re-run that report with the same parameters and it ran fine. We then went and took 100 of the random errored ones, ran them manually and they all worked fine.
My only straw left to grasp at is there is some caching or SSRS deep issue that is causing this.
If anyone has seen something similar or has an opinion on where to check next, would be much appreciated.
I just get start learning flink and try the case, "Real Time Reporting with the Table API "
When I ran docker-compose, all containers worked except jobmanager which is exited with 2.
up all
exit with 2
I tried rebuild and restart, but it does not work and I do not know what's wrong with it.
Could anyone help me to figure it out,please? Many thanks!
This particular tutorial does fail if you skip ahead and try to run it without first providing an implementation for org.apache.flink.playgrounds.spendreport.SpendReport.report. Several versions of that method are provided in the tutorial: pick one (perhaps the last one), drop it in, rebuild the docker image, and try again.
Ok Not sure what is going on here. I have runaway queries that won't cancel. I have one query to select all rows from a table that only has 250 rows and is 1.5KB in size. It's been running for 30 minutes right now and it should only take a few ms.
I've tried canceling by hitting the abort button on the worksheet, going into history and selecting the query and hitting abort, aborting based on the query ID via SQL, and aborting based on the session ID via SQL.
Ironically whenever I try to abort via SQL it shows that the queries have been terminated and then they still show as running, I wait a few minutes and re run the query and it again shows as terminated but they still are running.
I also tried loggin out and logging back in again and am seeing all kinds of weird errors:
Internal Error: Unable to retrieve the current roles.
Error
Problem with your MFA Enrollment: There was an issue with your enrollment
process. Please try again.
Worksheet Not Loaded
I have no idea what is going on but it seems like everywhere I turn there is an issue. Any assistance would be greatly appreciated.
Try logging completely out, close the browser, reboot your machine, and start from there. Here my guess:
Sometimes the query history (which I assume is where you were seeing things still running), needs a browser refresh, but based on MFA errors, refreshing your browser appears to have you logged out of your SAML/MFA process.
Once you successfully login, you'll likely see that the query had completed already before you even tried to cancel it.
If that isn't the case, and you are still seeing issues, then we'd probably need more information, or a quick call to Snowflake Support will walk you through things. My guess is this is all a display issue on your browser/UI, rather than something going wonky with Snowflake.
I am using CDC in SQL Server 2008 and triggering it via SSIS(In the form Stored procedures and calling commands like table-diff in EST). Recently i came across a different issue and I am simply not understanding what might be the reason. What exactly happened is CDC suddenly hanged while executing. It was in running state for almost around two days. After that we manually had to kill CDC process in order to run the next batch for the same. When I ran same CDC job next time it ran properly without any interruption (Completed in few minutes/No changes were made to package or anywhere before next execution).When that process was executing for around two days I checked changed records, except for 2-3 new Inserts/Updates nothing was there. After going through log file details I came to know my table-diff cmd took around 5 hours to execute which normally takes around 5 mins for my package everyday.I just want to know what might be the possible reason for such behaviour.
PS: Such behaviour occurred few times in past as well.
Running WSo2 EMM 1.1.0, everything has been working just fine except for one big issue.
From the moment I first click on an app in the App Management tab, the WSO2EMM_DB.h2.db file starts to steadily grow as long as the server is running, even with absolutely no changes. Eventually, it gets so big that clicking an app on that tab takes a ridiculously long time to load the list of devices using the app. We're talking 5+ minutes, it becomes completely unusable. I have checked the error logs and found no errors at all, every time.
Restarting the server does nothing to correct the issue. Even if I click an app on the App Management tab once, and never again, the database file will continue to grow. Even restarting the server and not logging into the EMM page, it will continue to grow.
The only thing I've found so far that can possibly help is keeping backup copies of the database file and overwriting the current file when it gets too big. Obviously that's not a solution, as I'd need to create a new backup file every time there's a change on the server, and eventually the database file would grow too big from that too.
It's not an issue with the H2 database either. Not only have I tried starting over fresh several times and have had the same behavior, but here is the only info I could find regarding this issue, and they were having the issue regardless of whether or not it was on H2 or MySQL.
I've been trying to find a solution for this for over a month with no success. Any help would be appreciated!
EDIT: It looks like this might be the subject of EMM-826. Unfortunately there seems to be no response to that bug report so far.
EDIT 2: EMM-826 was closed with a message saying the following:
This issue is fixed in the EMM 1.1.0 GA latest pack. Please get all the patches for the product/build the product from the latest source [ https://github.com/wso2/product-emm ] and try again.
Unfortunately, that did not work for me. I'm not sure what exactly I'm doing wrong, so I'll list the what I did to try to fix it:
Downloaded the EMM 1.1.0 zip from http://wso2.com/products/enterprise-mobility-manager/.
Downloaded the zip from https://github.com/wso2/product-emm and pasted the files from that into my EMM_HOME directory.
When that didn't work, I searched for patches and found I was only using patches 1-6. In the documentation I found I could download patches 7-12 here. Patches 9 and 10 didn't work right for some reason; causing me not to be able to reach the EMM dashboard or publisher. I could only access the Carbon manager. I was able to make patches 7, 8, 11, and 12 work though - with no change in behavior.
Here are the steps I take to reproduce the issue:
After setting a fresh copy of the EMM up, I log in to the EMM dashboard as Admin, set up a user account, and upload an app through the Publisher.
Register a device to the user account I set up. In this case, an Android device running Android 4.2.2.
From the dashboard, I go to App Management and click the app I uploaded. The list of devices loads, but from that point on, the database file starts growing and eventually, after several hours, becomes so large it the device list will never load.
Please help!
Found this happening also, from a quick look it's the WSO2EMM_DB.notifications table. Seems to keep a history of all notifications over time, and the info for app installs is taken from non-optimized queries, which degrade as the table grows. You 'could' delete all rows from the table, and it will re-populate as devices 'check back' and report their info.
But you'd probably want to write a query to just keep the latest notification of each type of each user (I'll leave that to someone else...) and as was mentioned, it is apparently fixed in the latest version.
Issue appears to be resolved in EMM 2.0, which can be found here.