[teiid-issues] [JBoss JIRA] (TEIID-4454) Close session called with null session id

[Steven Hawkins (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13296418#comment-13296418 ] 

Steven Hawkins commented on TEIID-4454:
---------------------------------------

> And this method will call closeSession without even checking if there is a session to logoff

Perhaps you are seeing something else.  What you are describing does not match the code as the logoff method does check for a null session id:

{code}
                if (workContext.getSession().isClosed() || workContext.getSessionId() == null) {
			if (workContext.getSessionId() != null) {
				this.updateDQPContext(new SessionMetadata());
			}
			return ResultsFuture.NULL_FUTURE;
		}
{code}

Are you using a server version older than when TEIID-3664 was committed?

> Close session called with null session id
> -----------------------------------------
>
>                 Key: TEIID-4454
>                 URL: https://issues.jboss.org/browse/TEIID-4454
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 9.0.4
>            Reporter: Wouter de Vaal
>            Assignee: Steven Hawkins
>            Priority: Minor
>
> When connecting locally via a JNDI resource to a vdb, we see in our audit log that an extra closeSession is logged with a null session id, just before a new session is created.
> This is probably because the class LocalServerConnection.authenticate calls logoff
> Logoff will execute a logoff command with swallowing all exceptions:
> 		try {
> 			//make a best effort to send the logoff
> 			Future<?> writeFuture = this.getService(ILogon.class).logoff();
> 			if (writeFuture != null) {
> 				writeFuture.get(5000, TimeUnit.MILLISECONDS);
> 			}
> 		} catch (Exception e) {
> 			//ignore
> 		}
> And this method will call closeSession without even checking if there is a session to logoff:
> 		try {
> 			this.service.closeSession(workContext.getSessionId());
> 		} finally {
> 			this.updateDQPContext(new SessionMetadata());
> 		}
> So fix should probably be adding an if statement to LogofImpl.logoff 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)