Had to nest questions because I don't have enough points to post more on the forum in a day.
We are attempting to get access permissions to the Postgresql logs but for now we only have limited information.
EXECUTE <unnamed> = DELETE FROM PUBLIC.MEMBERSHIPBASE WHERE USER_NAME=$1 AND GROUP=$2
The above will execute in a days time 36 million times. We have only a few hundred users.
Part of the issue we have is that the following call is running all the time and we do not know...
Attention JIRA SMEs Can you answer this 4.1.2 limited access question?
Users are able to post to the application via direct web service calls.
Users are not able to post to the application via the GUI. The GUI just hangs until it errors out and there is nothing in the logs to give us a clue as to why. Logging is set to FINE.
There have been no modifications to the application. The database provider informed us that they implemented a patch from 9.2.11 to 9.2.13 on Postgresql.
Are there any tools that JIRA has that can assist with tracking this down?
Due to restriction in posting I cannot add new comments only edit this one.
Will look into the Jelly thing to see what I can find in our codebase.
@Nic Brough [Adaptavist] Yes you are correct. We do have an external database. We have put in a request to obtain a full copy of the VM so we can duplicate in our test environment what is on production. They have given us only a dump of the db but that does us little good.
Looks like it's trying to delete a user and a group though together which I'm sure you can only do one or the other. Unless there is a jelly script sat on a listener? Can you see if the user/group it's trying to remove exist? I'm guessing you have blanked them out from the ubove description. Maybe create them so it can delete them and maybe it will realise it's performed it's task and stop.. I'd check the release notes on the next version up and see if the fault was fixed.
You're in a bad place - just tell them that you cannot possibly support an application that you do not have *full* access to. Not write, but you need the logs, real time, you need the network traffic, you need to be able to look around ALL of it. One simple way out of this though - raise the request with IT for a FULL working clone of the current systems. If they refuse, then the answer back really is "then YOU need to fix the issues with YOUR system that I cannot touch"
They finally gave our SA rights to view realtime logs and we were able to identify where in the code things had gone awry. A limit was set for the number of users allowed to be in cache for the User Browser. The number of users had been increased and exceeded that number which ended up in items being dropped from the cache and then required to put them back in but the cache could never hold all the users. PAINFUL situations. You guys have been helpful and appreciate that you took the time to try and assist. We are pushing hard for them to rebuild the system on a new version of JIRA but I keep telling them it's only worth doing if they require that the winning contractor provides the developers with the training to build it properly and not bastardize the source code. This item is CLOSED.
Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot