ALPSMAC commented on issue #49699:
URL: https://github.com/apache/arrow/issues/49699#issuecomment-4217593766
Closing - I was able to fix this by using the intended path for the python
client:
```python
# flight_ticket_pb = ...
ticket_bytes = flight_ticket_pb.ticket
# 2. Connect using the standard FlightClient
client = fl.connect("grpc://localhost:9090") # Your
flight server address
#
# 4. THIS IS THE CALL THAT WILL FAIL in a debuggable way.
# It directly calls the C++ FlightClient::DoGet method,
which
# then creates the ClientStreamReader internally.
#
try:
ticket = fl.Ticket(ticket_bytes)
reader = client.do_get(ticket) # This call will
likely throw the error directly now
# If it gets past here without an exception, the
object is valid.
# The segfault would then happen here, but it's
more likely to error above.
table = reader.read_all()
print("Success!")
comp_end_time = time.time()
print(f"Time to compute and stream back results:
{(comp_end_time - comp_start_time) * 1e6:.0f} microseconds")
print(f"\nReceived Arrow Table with
{table.num_rows} rows.")
print("Schema:")
print(table.schema)
print("\nFirst 5 rows:")
print(table.to_pandas().head())
```
I suspect what caused the original crash was a mismatch in `Ticket` types
generated by the python gRPC bindings... a type that's from a separate proto
file that links against the flight Ticket type, and the Ticket type built into
the flight pyarrow library. Sadly python let me call `client.do_get(...)` with
the type from the generated protos but segfaults in the guts of the arrow ipc
stuff when you do so.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
