You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "T Jake Luciani (JIRA)" <ji...@apache.org> on 2009/05/21 05:24:45 UTC
[jira] Created: (THRIFT-512) Implement TProtocol.setTransport()
Implement TProtocol.setTransport()
----------------------------------
Key: THRIFT-512
URL: https://issues.apache.org/jira/browse/THRIFT-512
Project: Thrift
Issue Type: Improvement
Components: Library (Java)
Affects Versions: 0.1
Reporter: T Jake Luciani
Priority: Minor
I'm working on a Rewindable or Peek transport that delegates to a base transport and buffers the read/write data for access later to the raw stream.
I'm also using TNonblockingServer that currently requires a TFramedTransport.Factory()
Rather than change TNonblockingServer to accept a TTransportFactory, it may be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out the protocol in the Processor before it starts to read/write.
I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-512) Implement TProtocol.setTransport()
Posted by "T Jake Luciani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711591#action_12711591 ]
T Jake Luciani commented on THRIFT-512:
---------------------------------------
A non-blocking server can only handle a framing transport so if we changed it there, i'd be concerned that it would cause cause confusion.
But if that is preferred I'm ok with it.
The use case I have is the need to log write operations. Rather than re-serializing objects to disk I'd like to capture them serialized off the wire.
> Implement TProtocol.setTransport()
> ----------------------------------
>
> Key: THRIFT-512
> URL: https://issues.apache.org/jira/browse/THRIFT-512
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.1
> Reporter: T Jake Luciani
> Priority: Minor
>
> I'm working on a Rewindable or Peek transport that delegates to a base transport and buffers the read/write data for access later to the raw stream.
> I'm also using TNonblockingServer that currently requires a TFramedTransport.Factory()
> Rather than change TNonblockingServer to accept a TTransportFactory, it may be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out the protocol in the Processor before it starts to read/write.
> I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-512) Implement TProtocol.setTransport()
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711469#action_12711469 ]
Todd Lipcon commented on THRIFT-512:
------------------------------------
Personally I prefer the design of having TNonblockingServer take a factory. Allowing the transport to change underneath a protocol seems like a dangerous operation. I'm not sure I entirely understand your use case, but couldn't this be achieved by fully wrapping a transport without any lib code changes?
> Implement TProtocol.setTransport()
> ----------------------------------
>
> Key: THRIFT-512
> URL: https://issues.apache.org/jira/browse/THRIFT-512
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.1
> Reporter: T Jake Luciani
> Priority: Minor
>
> I'm working on a Rewindable or Peek transport that delegates to a base transport and buffers the read/write data for access later to the raw stream.
> I'm also using TNonblockingServer that currently requires a TFramedTransport.Factory()
> Rather than change TNonblockingServer to accept a TTransportFactory, it may be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out the protocol in the Processor before it starts to read/write.
> I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (THRIFT-512) Implement TProtocol.setTransport()
Posted by "T Jake Luciani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
T Jake Luciani closed THRIFT-512.
---------------------------------
Resolution: Invalid
> Implement TProtocol.setTransport()
> ----------------------------------
>
> Key: THRIFT-512
> URL: https://issues.apache.org/jira/browse/THRIFT-512
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.1
> Reporter: T Jake Luciani
> Priority: Minor
>
> I'm working on a Rewindable or Peek transport that delegates to a base transport and buffers the read/write data for access later to the raw stream.
> I'm also using TNonblockingServer that currently requires a TFramedTransport.Factory()
> Rather than change TNonblockingServer to accept a TTransportFactory, it may be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out the protocol in the Processor before it starts to read/write.
> I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-512) Implement TProtocol.setTransport()
Posted by "T Jake Luciani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711842#action_12711842 ]
T Jake Luciani commented on THRIFT-512:
---------------------------------------
"why not make a wrapper transport that just hangs on to a copy of everything"
I only want to log write operations so my plan was to extend the Processor and "peek" at which operation is being called. in c++ lib there is a TPipedTransport that does what you describe.
I may just be over engineering at this point...
> Implement TProtocol.setTransport()
> ----------------------------------
>
> Key: THRIFT-512
> URL: https://issues.apache.org/jira/browse/THRIFT-512
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.1
> Reporter: T Jake Luciani
> Priority: Minor
>
> I'm working on a Rewindable or Peek transport that delegates to a base transport and buffers the read/write data for access later to the raw stream.
> I'm also using TNonblockingServer that currently requires a TFramedTransport.Factory()
> Rather than change TNonblockingServer to accept a TTransportFactory, it may be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out the protocol in the Processor before it starts to read/write.
> I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-512) Implement TProtocol.setTransport()
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711680#action_12711680 ]
Bryan Duxbury commented on THRIFT-512:
--------------------------------------
I agree with Todd that resetting the transport under the protocol seems a little sketchy.
If your goal is to log operations, then why not make a wrapper transport that just hangs on to a copy of everything? It seems like it would be a lot simpler than rewinding or something like that.
A wrapper transport of some kind could come from a factory. In order to make the factory stuff unconfusing in relation to TNonblockingServer, we could always just wrap the user provided factory with a framed one.
> Implement TProtocol.setTransport()
> ----------------------------------
>
> Key: THRIFT-512
> URL: https://issues.apache.org/jira/browse/THRIFT-512
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.1
> Reporter: T Jake Luciani
> Priority: Minor
>
> I'm working on a Rewindable or Peek transport that delegates to a base transport and buffers the read/write data for access later to the raw stream.
> I'm also using TNonblockingServer that currently requires a TFramedTransport.Factory()
> Rather than change TNonblockingServer to accept a TTransportFactory, it may be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out the protocol in the Processor before it starts to read/write.
> I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.