Unexpected error when updating a shared prototype (V7.2.1), what can we do to recover from this?
When we are working on a shared prototype (this has happened 3 times, once after 304 updated, once after 34 updates and once after 1 update), one of the 2 people that are working in the shared prototype received and Unexpected Error, update cannot be completed and the software restarts. 2 of the times it happened to the shared user and once it happen to the owner of the prototype.
Hi Dave,
We're sorry that you're encountering this. In order to assist you, could you send an email with the log files so we can get some more info about why this is happening?
You can find the logs by going to:
On PC: C://users/youruser/Justinmind[version]/logs.log
On Mac [folder of the user]/justinmind/version/logs.log
Best,
Sonia Durán
Hi Dave,
We're sorry that you're encountering this. In order to assist you, could you send an email with the log files so we can get some more info about why this is happening?
You can find the logs by going to:
On PC: C://users/youruser/Justinmind[version]/logs.log
On Mac [folder of the user]/justinmind/version/logs.log
Best,
Sonia Durán
Hello Sonia
I am running into the same issue with V 7.8
Hello Sonia
I am running into the same issue with V 7.8
Hi Justin,
We're sorry that you're encountering this. In order to assist you, we will need the log files. Could you please ask the account owner of your license to send them through our Customer Support Portal?
You can find the logs by going to:
On PC: C://users/youruser/Justinmind[version]/logs.log
On Mac [folder of the user]/justinmind/version/logs.log
Best,
Sonia Durán
Hi Justin,
We're sorry that you're encountering this. In order to assist you, we will need the log files. Could you please ask the account owner of your license to send them through our Customer Support Portal?
You can find the logs by going to:
On PC: C://users/youruser/Justinmind[version]/logs.log
On Mac [folder of the user]/justinmind/version/logs.log
Best,
Sonia Durán
I am (was) getting this same error. Nothing in the support pages worked - from what I was able to see concerning resolutions. All I've seen from JiM support people is some response about 'send the logs' - which puts one out of action for who-knows-how-long.
So in an attempt to fix things myself, I randomly stumbled on the capability embedded into 8.0 (it may be in previous versions too) wherein you can "Commit" particular folders and/or files. Since I last made a Commit action, I've created about 20 new screens and three new folders. I suspect the Commit action failed because there was too much to 'update' on the server version of my project. There is one other collaborator on my project and he had the same project open, but working on totally different screens in totally different folders. He was able to Commit his changes (since his last update) and Unlock those pages he had been working within - so my point here is that my other collaborator seemed to be working ok concerning Commit and Unlock actions. It was my problem alone at this point. We're using the exact same JiM application version and the exact same hardware...and for what it's worth, the exact same network connection.
Since I wasn't able to do a Commit All action, I tried right-clicking one of the three folders I had made. To my surprise, it worked! Although, the summary screen during the Commit process seemed to indicate I was simply Committing the folder itself...and not the files within it. Anyway, I went to the other two folders remaining and the Commit action worked on them as well - in the same way. Pushing my luck, I right-clicked on a single screen I was working within and did a Commit action on "it". Surprise - it worked! Although - this time the summary screen indicated that it was Committing all the screens I had worked within. Trying to reassure myself that all my changes since opening the project were now Committed, I did a Commit All action and had no problem whatsoever.
I suspect the load of my changes being Committed had something to do with the "Unexpected Error. The Commit process could not be completed" - or something like that (I didn't write down the exact error). I.e., if you have a couple of screens that are being committed to the server everything should work fine. But if you've created a ton of stuff (screens, folders, etc.) then you may run into this error.
Hope this helps others.... Would love to hear what JiM support people have to say about this potential 'overflow' theory during a Commit action...
- Jeff (Atlanta..and sometimes Dallas)
I am (was) getting this same error. Nothing in the support pages worked - from what I was able to see concerning resolutions. All I've seen from JiM support people is some response about 'send the logs' - which puts one out of action for who-knows-how-long.
So in an attempt to fix things myself, I randomly stumbled on the capability embedded into 8.0 (it may be in previous versions too) wherein you can "Commit" particular folders and/or files. Since I last made a Commit action, I've created about 20 new screens and three new folders. I suspect the Commit action failed because there was too much to 'update' on the server version of my project. There is one other collaborator on my project and he had the same project open, but working on totally different screens in totally different folders. He was able to Commit his changes (since his last update) and Unlock those pages he had been working within - so my point here is that my other collaborator seemed to be working ok concerning Commit and Unlock actions. It was my problem alone at this point. We're using the exact same JiM application version and the exact same hardware...and for what it's worth, the exact same network connection.
Since I wasn't able to do a Commit All action, I tried right-clicking one of the three folders I had made. To my surprise, it worked! Although, the summary screen during the Commit process seemed to indicate I was simply Committing the folder itself...and not the files within it. Anyway, I went to the other two folders remaining and the Commit action worked on them as well - in the same way. Pushing my luck, I right-clicked on a single screen I was working within and did a Commit action on "it". Surprise - it worked! Although - this time the summary screen indicated that it was Committing all the screens I had worked within. Trying to reassure myself that all my changes since opening the project were now Committed, I did a Commit All action and had no problem whatsoever.
I suspect the load of my changes being Committed had something to do with the "Unexpected Error. The Commit process could not be completed" - or something like that (I didn't write down the exact error). I.e., if you have a couple of screens that are being committed to the server everything should work fine. But if you've created a ton of stuff (screens, folders, etc.) then you may run into this error.
Hope this helps others.... Would love to hear what JiM support people have to say about this potential 'overflow' theory during a Commit action...
- Jeff (Atlanta..and sometimes Dallas)
Dear Jeff,
You're probably right, however, this is not happening on our server, so it seems that some special settings of the server have not been properly configured. That's the reason why we usually ask for the log files to those users that are experiencing this, because it would help us to see why this might be happening.
Best,
Dear Jeff,
You're probably right, however, this is not happening on our server, so it seems that some special settings of the server have not been properly configured. That's the reason why we usually ask for the log files to those users that are experiencing this, because it would help us to see why this might be happening.
Best,
The server instance I'm speaking about is one owned and managed by justinmind. I.e., the usernote server I'm referring to is https://www.justinmind.com/usernote. I do use two different versions - one 7.9 and one 8.0 - each on separate computers with separate licensing contracts and UIDs/Pwds (I serve two different sets of clientele.) What I'm referring to in my previous comment is all about the 8.0 instance, exclusively, in this case.
So the situation described in the previous posting has a cause rooted somewhere in the 8.0 (Win) application itself or the Usernote instance hosted by Justinmind themselves. I've run across it before in prior versions but it cannot be reproduced on a whim...it's just something I've run into on occasion. What I've come to notice recently with the "Commit" actions on a per-folder and per-screen basis is that it seems to be needed only when I have a larger-than-usual number of screens and folders being created/added to an existing prototype on the Usernote server. I can speculate there's some Java overflow on the client or server, or perhaps there exists a locked 'limit' setting that refuses changes over a given size when the 'Commit All' action is initiated...but I truly don't know for sure. I do know that this work-around (aforementioned) has relieved me from having to post the new/changed prototype back into the Usernote instance as a 'new' prototype....because the only other alternative (until discovering the per-file/per-folder 'Commit' solution) was to discard any changes I had made and start from whatever version of the prototype existed on the Usernote instance when I began working that day.
Someone somewhere HAS to know - or suspect - what's going on when us users get the "Unexpected Error. The Commit action cannot be completed....." there in the Justinmind development shop. Whatever those suspicions are, I would love to see them posted as hypotheses (at least) so that us Users can try and help...without opening tickets and sending our log files every time. Time is valuable when billing by the hour. Clients want to see progress each day. Losing work is unacceptable. But, we have free time to help figure things out. Especially when we sort of make our livelyhood on products such as JiM.
Thanks - Jeff
The server instance I'm speaking about is one owned and managed by justinmind. I.e., the usernote server I'm referring to is https://www.justinmind.com/usernote. I do use two different versions - one 7.9 and one 8.0 - each on separate computers with separate licensing contracts and UIDs/Pwds (I serve two different sets of clientele.) What I'm referring to in my previous comment is all about the 8.0 instance, exclusively, in this case.
So the situation described in the previous posting has a cause rooted somewhere in the 8.0 (Win) application itself or the Usernote instance hosted by Justinmind themselves. I've run across it before in prior versions but it cannot be reproduced on a whim...it's just something I've run into on occasion. What I've come to notice recently with the "Commit" actions on a per-folder and per-screen basis is that it seems to be needed only when I have a larger-than-usual number of screens and folders being created/added to an existing prototype on the Usernote server. I can speculate there's some Java overflow on the client or server, or perhaps there exists a locked 'limit' setting that refuses changes over a given size when the 'Commit All' action is initiated...but I truly don't know for sure. I do know that this work-around (aforementioned) has relieved me from having to post the new/changed prototype back into the Usernote instance as a 'new' prototype....because the only other alternative (until discovering the per-file/per-folder 'Commit' solution) was to discard any changes I had made and start from whatever version of the prototype existed on the Usernote instance when I began working that day.
Someone somewhere HAS to know - or suspect - what's going on when us users get the "Unexpected Error. The Commit action cannot be completed....." there in the Justinmind development shop. Whatever those suspicions are, I would love to see them posted as hypotheses (at least) so that us Users can try and help...without opening tickets and sending our log files every time. Time is valuable when billing by the hour. Clients want to see progress each day. Losing work is unacceptable. But, we have free time to help figure things out. Especially when we sort of make our livelyhood on products such as JiM.
Thanks - Jeff
Replies have been locked on this page!