accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Berman (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (ACCUMULO-1729) ThriftTransport pool does not include ssl options in cache key
Date Thu, 31 Oct 2013 17:59:18 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Berman reassigned ACCUMULO-1729:
----------------------------------------

    Assignee: Michael Berman

> ThriftTransport pool does not include ssl options in cache key
> --------------------------------------------------------------
>
>                 Key: ACCUMULO-1729
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1729
>             Project: Accumulo
>          Issue Type: Sub-task
>            Reporter: Keith Turner
>            Assignee: Michael Berman
>             Fix For: 1.6.0
>
>
> This ticket was created based on the following [comment|https://issues.apache.org/jira/browse/ACCUMULO-1009?focusedCommentId=13772055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13772055]
from [~mberman] in ACCUMULO-1009. I copied the comment in case the link comment stops working.
 
> {quote}
> Multiple ZooKeeperInstances in the same java process with different SSL config (is this
possible? It looks like you included ssl options in the Key in ThriftTransportPool?) This
could happen if a single process connected to multiple Accumulo instances
> {quote}
> Generally this should be fine.  The cached transports are keyed on (location, timeout,
sslEnabled), so if you're connecting to multiple instances from the same process, they should
have different locations anyway, so the different SSL settings will be segregated.  One potential
area for concern is that I'm only using the sslEnabled flag, not the full set of SSL parameters,
so if you have connected successfully with some cert, and then in the same process you try
to connect with a different cert, you could get a cached, connected transport, even though
you might not otherwise trust the remote server (or you might have an invalid client cert,
if that's turned on).  It seemed to me like this risk was pretty minimal, since you're already
in the same process, but if others think it's too big a risk, it would be easy to add all
the SSL params to the key.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message