Jump to content


IServer.login() sometimes fails in web application, .p4tickets FileNotFoundException

p4java p4tickets

  • Please log in to reply
3 replies to this topic

#1 guinyardlives

guinyardlives

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 17 June 2014 - 08:09 PM

We're seeing a problem in a web app, running in weblogic on Solaris, where IServer.login() periodically fails if two threads call it at nearly the same time.  The code seems to follow the typical p4java usage pattern described here: in servicing a servlet request, a thread obtains a new IService instance, logging-in, obtaining an IClient, adding a file, and submitting.  Majority of the time it works fine.  When it fails, the root cause is:


Caused by: java.io.FileNotFoundException: /export/home/webluser/.p4tickets (Permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at com.perforce.p4java.server.AuthTicketsHelper.copy(AuthTicketsHelper.java:345)
at com.perforce.p4java.server.AuthTicketsHelper.saveTicket(AuthTicketsHelper.java:314)
at com.perforce.p4java.server.AuthTicketsHelper.saveTicket(AuthTicketsHelper.java:224)
at com.perforce.p4java.impl.mapbased.rpc.RpcServer.saveTicket(RpcServer.java:515)

My guess is both threads call IServer.login(), both decide a new ticket value should be stored and attempt to update the .p4tickets file at nearly the same instant, one succeeds and the other fails.  

So if my Cultural Learnings of Perforce for Make Benefit Glorious Corporation of America is correct, yes?, then I have a few questions hopefully someone can help me with:

- What should I do?  Some of my ideas include:
  • Copy .p4tickets into a temp file, tell IServer to use the temp file.  That way each thread would be operating on its own single-use temporary .p4tickets file.
  • If login() typically doesn't write to the .p4tickets file, only writing to it when it decides a new ticket should be stored, then it seems like immediately re-trying the login() call should always succeed, right?
- Are there other .p4tickets contention problems I've yet to uncover?  If thread A is happily adding a file while thread B updates the .p4tickets file, even though they're operating on separate IServer objects, will thread A's submit be botched?

Thanks!

#2 P4Shimada

P4Shimada

    Advanced Member

  • Members
  • PipPipPip
  • 831 posts

Posted 18 June 2014 - 08:53 PM

Hi,

I am not sure which version of P4Java you are using but the permissions error
with p4tickets could be related to one of these issues here listed in the
P4Java release notes that were fixed in 2009.2 versions:

http://www.perforce....p4javanotes.txt

#217317 (Bug #35376)
   P4Java authentication ticket system now checks properties for
   relevant property definitions when saving a ticket value.

#217319 (Bug #35378)
   Tickets files used by P4Java are no longer set read-only with JDK5
   and / or Windows systems.

I am not sure if the issue has to do with an incorrect ticket path
where P4JProperties is ignored in P4JServerFactory.getServer() or the
tickets set byh P4Java are read only. However, you can try these work-arounds:
  • Use the environment variable "P4TICKETS" instead of the property and that should work.  Also if you add the following line before  you actually request any servers it should fix the read-only issue:

P4JServerFactory.setRpcFileSystemHelper(new P4JRpcSystemFileCommandsImpl());
  • See if it runs without error if you remove the p4tickets.txt file


#3 guinyardlives

guinyardlives

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 18 June 2014 - 10:28 PM

Ok, so it sounds like our best bet is to move up to the latest 2013.2 so that we get whatever the fix was for:
	#615005 (Bug #64015)
		Fixed a problem with user auth tickets sharing a singleton storage
		when the same user is used in multiple RPC connections logging in
		and out frequently.
and even better, tell it to not use the tickets file at all with:
	#525729 (Bug #59814)
		Added in-memory storage for auth tickets and fingerprints.
		By default, P4Java uses files to store auth tickets and SSL
		connection fingerprints. To turn on in-memory storage of auth
		tickets and fingerprints set the "useAuthMemoryStore" or the
		long form "com.perforce.p4java.useAuthMemoryStore" property
		to "true" (or anything) when requesting an IOptionServer from
		the ServerFactory.
Am I correct in assuming useAuthMemoryStore will prevent it from ever reading or writing to .p4tickets?

#4 P4Shimada

P4Shimada

    Advanced Member

  • Members
  • PipPipPip
  • 831 posts

Posted 19 June 2014 - 04:44 PM

Yes, this feature via 'useAuthMemoryStore' was added so users have the ability to not use the tickets file.
Thus in-memory storage for auth tickets and fingerprints was implemented.

By default, P4Java uses files to store auth tickets and SSL connection fingerprints.
With this new feature, the user can turn on in-memory storage by passing a property
to the ServerFactory when requesting an IOptionsServer object. The property key can be
either the short form "useAuthMemoryStore" or the long form "com.perforce.p4java.useAuthMemoryStore"





Also tagged with one or more of these keywords: p4java, p4tickets

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users