Nothing been changed, user getting started to not able to import model into Rhapsody DM project area
Env:Rhapsody DM 4.x, Websphere Server v8.0.x, Derby DB, Websphere Federated repository.
No change done on the User01 both for license and permission and project role info.
Later using User01 to add more user accounts in Websphere and JTS, and then assigned the floating license to each user account.
After repeating user login/logout for each new added user account successfully.
Login DM by User01 again and start to import model into the same project area, Client browser showing error message like " this user has no permission for this operation"
In dm.log, error message is "com.ibm.xtools.rmps.frontservice.jfsclient.RmpsRuntimeException: 400 (ERROR) :RHAPERR:invalidPermissions
"
In my understanding, only if design manager license is not granted or required roles are not assigned to the user, the import operation could be rejected.
Strange thing is, In this case, User01 has ever successfully imported a model into the same project area and no change been done on the User01 info itself. why after creating more user, suddenly importing operation is failed for User01?
Anyone can give me some hints?
Where I need to take a check?
What could be the possible causes?
Thank You
15 answers
I paste the stack info here, can you see some issues below?
com.ibm.xtools.rmps.frontservice.jfsclient.RmpsRuntimeException: 400 (ERROR) :RHAPERR:invalidPermissions
at com.ibm.rational.carter.util.PermissionValidator.validateUserPermission(PermissionValidator.java:48)
at com.ibm.rational.carter.publish.PublishFrontService.rmpsPost(PublishFrontService.java:217)
at com.ibm.xtools.rmps.frontservice.RmpsFrontService.rmpsService(RmpsFrontService.java:366)
at com.ibm.xtools.rmps.frontservice.RmpsFrontService.doPost(RmpsFrontService.java:548)
at com.ibm.team.jfs.app.servlet.AppContainerServlet.dispatchRequest(AppContainerServlet.java:176)
at com.ibm.team.jfs.app.servlet.AppContainerServlet.service(AppContainerServlet.java:281)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(AbstractTeamServerServlet.java:1640)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1214)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:774)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:456)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:125)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:92)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.processDelegate(BridgeFilter.java:133)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.doFilter(BridgeFilter.java:154)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:192)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:89)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:926)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1023)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:895)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.determineNextChannel(SSLConnectionLink.java:1049)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink$MyReadCompletedCallback.complete(SSLConnectionLink.java:643)
at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1784)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659)
Hi, Daniel
Thanks for your suggestion.
But unfortunately things are not getting improved ever after deleting the cache/cookies of the browser or start a new window or restart the server.
As all the created user accounts could be successfully login/logout, I think the user info stored in WAS is correct. Just JTS couldn't grant the user with the permission to import model though it should be supposed to as the user had ever imported a model successfully.
Hi, Daniel, can you explain some info regarding below? Thank you in advance.
(1) Whether it's JTS used for handling floating licenses? I have assigned totally 5 floating licenses to 13 users. It shouldn't be an issue, I believe.
(2) The problem was first time detected right after creating a group of users and doing login/logout for each new created users successfully.
Do you think the database info is possibly not correct or partially broken?
Is there a way to check whether the database information is correctly stored or not?
(3) Do you think I need to configure JTS again(re-setup)? In that case, whether I need to register all the user info from right beginning?
Next time, I'm thinking to try the import on another project area.
Right now I really don't have any idea to understand what actually could be the root cause? Any point else you can suggest me to check or test?
Thank You
Best Regards
Hi, Daniel
If you could recommend someone who is the expert on this area, I want to know according to the log tracing I pasted above, whether you can judge the runtime exception was occurred inside of JTS or it was reported by the registered RDM(Rhapsody DM) application?
I think the license info is managed by JTS, but the user roles to a specific Project Area should be managed on RDM.
If User doesn't have required license or hasn't been assigned with the required project role, (import) operation permission error would happen. So I want to first make sure what application reported the permission error.
Thank You for kind help
Regards
Hi Jin,
RDM application is checking the user permissions before the import operation begin.
This check is indeed depends on the required license and the assigned project roles.
So my guess is that the problem is with assigning the floating licenses.
Did you try to remove the license from the new users? Does it helped?
Can you please check if user01 still has a license assigned after setting a license to the new users?
Yuval
Comments
>>Did you try to remove the license from the new users? Does it helped?
I will try this, thx.
Hi, Yuval
Can I continue to confirm sth details with you regarding your previous answer.
(1) When RDM check the user permission before import, does RDM first check client license and then check assigned project roles? or taking the reverse turn?
From the web client, we double checked user01 has been assigned with design manager floating license and all the project area related access permissions already.
The strange thing is user01 can successfully add a OSLC link to previously imported model artifact and further saved the change without error. I think modifying model resource is also requiring design manager license.
(2) I found some doc mentioned Derby database can only handle up to 10 users. In my client machine, they totally created 13 users, would it be a potential problem? If so, any possible way to fix?
By the way, my client tried to achieve other users but error still occurred.
Regards
Hi Jin,
To debug this further you may also want to look at the "Monitoring and releasing your licenses" topic at http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m2/index.jsp?topic=%2Fcom.ibm.jazz.repository.web.admin.doc%2Ftopics%2Fc_managing_licenses.html
You can run a report to see who has the licenses from the License Key Administration area on the Server tab of the JTS admin page.
Dan
To debug this further you may also want to look at the "Monitoring and releasing your licenses" topic at http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m2/index.jsp?topic=%2Fcom.ibm.jazz.repository.web.admin.doc%2Ftopics%2Fc_managing_licenses.html
You can run a report to see who has the licenses from the License Key Administration area on the Server tab of the JTS admin page.
Dan
Comments
Thanks, Daniel
Customer checked this right after the import was failed. There was no user occupying any floating license at that moment.
Could it be possible JTS stopped to grant any license to client request?
Hi, Daniel
I tested on another server and found after successfully imported a model into RDM,
I can see a license has been consumed by the current login user from "Acquired Floating Licenses" page.
But the same information couldn't been checked from the generated report,.though I'm quite sure I have entered the correct start/end date.
Regards
I did a test with RSA DM. I added a floating Designer license to the server, but with only 2 licenses available. I created three separate users, giving them each a floating license. What this means is that only 2/3 users can perform licensed activities at the same time.
I created a project area as user1 and uploaded a model. No problem. I logged in as user2 and created a project area - this triggers a licenses check. Now both of the floating licenses are assigned. I logged in as user3 - simply logging in does not trigger a license check. I tried creating a project as user3 and was denied because there were no more floating licenses available.
If you log into /jts/admin and navigate to Users > Acquired Floating Licenses, you can see all of the floating licenses that are currently in use. It is possible to terminate a license (see the X in the Actions column). I did this to my user1 license. Now user3 can create a project. Both floating licenses are assigned, to user2 and user3.
I logged out as user1. I logged back in. No license check yet. I tried to import my model again. The request was immediately denied with "You do not have permission to request an input. Please contact your server administrator." In essence, this is because user1 does not currently have a license. It has nothing to do with changing user1's licenses/permissions, but rather with the fact that the floating license server has no more licenses to give right now.
In this case, I would go to the Acquired Floating License page and terminate one of the existing licenses so that user1 can perform the import. Alternatively, perhaps more floating licenses are required.
I created a project area as user1 and uploaded a model. No problem. I logged in as user2 and created a project area - this triggers a licenses check. Now both of the floating licenses are assigned. I logged in as user3 - simply logging in does not trigger a license check. I tried creating a project as user3 and was denied because there were no more floating licenses available.
If you log into /jts/admin and navigate to Users > Acquired Floating Licenses, you can see all of the floating licenses that are currently in use. It is possible to terminate a license (see the X in the Actions column). I did this to my user1 license. Now user3 can create a project. Both floating licenses are assigned, to user2 and user3.
I logged out as user1. I logged back in. No license check yet. I tried to import my model again. The request was immediately denied with "You do not have permission to request an input. Please contact your server administrator." In essence, this is because user1 does not currently have a license. It has nothing to do with changing user1's licenses/permissions, but rather with the fact that the floating license server has no more licenses to give right now.
In this case, I would go to the Acquired Floating License page and terminate one of the existing licenses so that user1 can perform the import. Alternatively, perhaps more floating licenses are required.
Comments
Hello, Michelle
Thanks for your detailed input, I totally understand the scenario you elaborated above.
But my customer's case I described in the top post is a little different.
They did assign floating licenses to per user(totally 13 users), but before customer logging as user1 to try import, they just repeated login/logout for all the new created users. As you explained above, user login/logout won't consume license so it's hard to consider there is no available floating license for check out.
Hello, Michelle
Continue to above.
Even after customer restarted the server, situation is not change, no user can successfully import the model.
Right now, I suggested my customer to create new project area and try import;
run the license consuming report up till now.
reinstall the floating license to JTS server.
assign floating license to less than 5 users.
This issue is really weird, I couldn't reproduce the same in my test machine.
If unfortunately all the suggestions don't work on customer's side, do you think it's good a idea to re-setup JTS server? recreate all the user accounts in JTS after setup?
From the dm.log, jts.log, there is no specific messages reporting license related error
which makes it more difficult to pinpoint the root reason.
Thank You
Best Regards
Comments
Thank you, Peter.
Customer is actually using WAS 8.0.0.3.
As what you described, I have ever learnt in some cases, after logout from the previous user and login again with another user account, the previous user credential session could still be active and be reused. I suggested the customer clean the browser history and cookies before retrying import, but unfortunately the situation won't be improved.
I would ask the customer check the setting in WAS side you suggested above.
Since the customer first time successfully imported a model till the issue being detected, what customer has done to RDM and WAS is adding new users and assign licenses. But I think it's also possible customer forgot something they've done on the settings.
Hi Jin,
It's probably will be easier to report a defect and attach the logs there.
Thanks.
Sasha.
page 1of 1 pagesof 2 pages