หยุดการสิ้นสุดเซสชันการแก้ไขโค้ดที่ 10 นาที

หากเอกสาร CODE ตัดการเชื่อมต่ออย่างสม่ำเสมอหลังจากประมาณ 10 นาที ให้ตรวจสอบเส้นทาง WebSocket ผ่านพร็อกซีแบบย้อนกลับหรือตัวกระจายโหลดทุกตัวก่อน การหมดเวลาการใช้งาน 600 วินาทีเป็นเบาะแสการกำหนดค่าทั่วไป แต่เวลาเพียงอย่างเดียวไม่ได้พิสูจน์ว่าพร็อกซีเป็นสาเหตุ ตรวจสอบว่าส่วนประกอบใดปิดการเชื่อมต่อก่อนที่จะเปลี่ยนการตั้งค่า ในการใช้งานส่วนใหญ่ วิธีแก้ไขที่ได้ผลคือการคงการอัปเกรด Collabora WebSocket ไว้ และตั้งค่าการหมดเวลาการอ่านและการส่งของพร็อกซีให้นานกว่าเซสชันการแก้ไขที่คาดว่าจะนานที่สุด

ขั้นแรก ให้ตรวจสอบว่าการตัดการเชื่อมต่อเกิดขึ้นที่จุดใด

Collabora Online ใช้การเชื่อมต่อผ่านเบราว์เซอร์ไปยังเซิร์ฟเวอร์ CODE ในขณะที่การรวมเอกสารยังอาศัยการสื่อสาร WOPI กับโฮสต์ เช่น Nextcloud คำแนะนำเกี่ยวกับ reverse-proxy ของ Collabora และตัวอย่าง Office ปัจจุบันของ Nextcloud ได้ระบุเส้นทาง WebSocket แยกต่างหากสำหรับเซสชันเอกสาร หากเส้นทางนั้นหายไป ส่งไปยัง upstream ที่ไม่ถูกต้อง หรือถูกควบคุมโดยการหมดเวลาการใช้งาน โปรแกรมแก้ไขอาจสูญเสียการเชื่อมต่อแบบเรียลไทม์ ในขณะที่หน้าเว็บยังคงสามารถเข้าถึงได้

นั่นเป็นข้อกำหนดทางสถาปัตยกรรมที่ได้รับการยืนยันแล้ว ไม่ได้หมายความว่าความล้มเหลวทุกๆ สิบนาทีจะมีสาเหตุเดียวกันเสมอไป ตัวจัดการโหลดบนคลาวด์ ตัวควบคุมขาเข้า ไฟร์วอลล์ VPN หรือพร็อกซีอื่นๆ อาจกำหนดข้อจำกัดของตนเอง ให้ถือว่าช่วงเวลาที่สามารถทำซ้ำได้เป็นแนวทาง จากนั้นตรวจสอบบันทึกการเข้าถึงและบันทึกข้อผิดพลาดในขณะที่เกิดความล้มเหลว

1. บันทึกเวลาที่การเชื่อมต่อหลุดอย่างแม่นยำ และระบุว่าเกิดขึ้นขณะกำลังพิมพ์หรือขณะที่เอกสารอยู่ในสถานะไม่ได้ใช้งาน
2. ในเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ ให้เปิดแผงเครือข่าย กรองหา “WS” และตรวจสอบการเชื่อมต่อที่มีพาธลงท้าย/wsด้วย <network.net /cool/> จดบันทึกสถานะและปิดโค้ดหากเบราว์เซอร์รายงานสถานะดังกล่าว
3. ในเวลาเดียวกัน ให้ตรวจสอบบันทึกของรีเวิร์สพร็อกซีหรืออินเกรส บันทึกของเซิร์ฟเวอร์ CODE และบันทึกของโฮสต์ WOPI มองหาข้อความหมดเวลาของพร็อกซี การรีเซ็ตอัปสตรีม การปิด WebSocket ที่ผิดปกติ หรือข้อผิดพลาดของ WOPI ข้อความในบันทึกจะแตกต่างกันไปตามผลิตภัณฑ์และเวอร์ชัน ดังนั้นอย่าคิดว่าข้อความเดียวใช้ได้กับทุกผลิตภัณฑ์

หากการเชื่อมต่อ WebSocket สิ้นสุดลงที่ช่วงเวลา 600 วินาทีตามที่กำหนดไว้ ให้แก้ไขพร็อกซีหรือตัวกลางที่เป็นเจ้าของช่วงเวลานั้น แต่หากสิ้นสุดลงในช่วงเวลาอื่น หรือบันทึกแสดงข้อผิดพลาด WOPI หรือข้อผิดพลาดของเซิร์ฟเวอร์ ให้ตรวจสอบตามหลักฐานเหล่านั้นแทน เอกสารการแก้ไขปัญหาของ Nextcloud แนะนำเป็นพิเศษให้ตรวจสอบการเชื่อมต่อทั้งสองทิศทางและตรวจสอบบันทึกของทั้ง Nextcloud และ Collabora

เปิดใช้งาน WebSocket ผ่านทางพร็อกซีไว้เสมอ

ก่อนแก้ไขไฟล์พร็อกซี ให้ระบุโฮสต์เสมือนที่ใช้งานอยู่ และรูปแบบและพอร์ตอัปสตรีมจริงสำหรับ CODE สำรองข้อมูลการกำหนดค่าและตรวจสอบไวยากรณ์ก่อนโหลดใหม่ ตัวอย่างด้านล่างแสดงพฤติกรรม WebSocket ที่จำเป็นสำหรับพร็อกซีแบบย้อนกลับของ NGINX ซึ่งไม่ใช่โฮสต์เสมือน Collabora ที่สมบูรณ์ ผสานรวมเข้ากับการกำหนดค่าอย่างเป็นทางการสำหรับการใช้งานของคุณ โดยรักษาบล็อกตำแหน่งอื่นๆ การตั้งค่า TLS การจัดการ URI และกฎความปลอดภัยไว้

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

ส่วน หัว Upgrade`and` Connectionช่วยให้คำขอ HTTP เปลี่ยนไปใช้ WebSocket ขีดจำกัดการอ่านและการส่งที่นานขึ้นจะป้องกันไม่ให้พร็อกซีนี้ปิดการเชื่อมต่อแบบเงียบหลังจากช่วงเวลาเริ่มต้นสั้นๆ นี่ไม่ใช่คำสั่งให้เปิดเซสชันไว้ตลอดไป ปรับที่อยู่อัปสตรีมและการตรวจสอบ TLS ให้ตรงกับการติดตั้งของคุณ และอย่าปิดใช้งานการตรวจสอบใบรับรองเพียงเพื่อให้ตัวอย่างใช้งานได้

ตัวอย่างพร็อกซีอย่างเป็นทางการของ Collabora เป็นแหล่งข้อมูลหลักสำหรับการกำหนดค่าการกำหนดเส้นทางที่สมบูรณ์และเหมาะสมกับเวอร์ชัน คำแนะนำปัจจุบันของพวกเขารวมถึงการตั้งค่าหมดเวลาพร็อกซีที่ยาวนาน ตัวอย่าง Docker ปัจจุบันของ Nextcloud ก็มี/cool/(.*)/wsการแมป WebSocket โดยเฉพาะเช่นกัน ควรใช้ตัวอย่างที่สมบูรณ์เหล่านั้นแทนที่จะแทนที่โฮสต์เสมือนทั้งหมดของคุณด้วยส่วนเล็กๆ นี้:

• การตั้งค่าพร็อกซีแบบย้อนกลับของ Collabora Online
• ตัวอย่างการติดตั้ง Nextcloud 35 บน Docker

สำหรับ NGINX ให้รันnginx -tและรีโหลดหลังจากที่การทดสอบสำเร็จแล้วเท่านั้น สำหรับ Apache ให้ใช้การทดสอบการกำหนดค่าก่อนรีโหลด หาก CODE ทำงานอยู่เบื้องหลัง Kubernetes ingress หรือ Cloud Load Balancer การเปลี่ยน NGINX บนโฮสต์ CODE จะไม่แก้ไขปัญหาการหมดเวลาที่สั้นลงที่ ingress หรือ provider edge ให้ทำการอัปเดตส่วนประกอบที่บันทึกระบุไว้

ตรวจสอบทุกจุดเชื่อมต่อเครือข่าย ไม่ใช่แค่รหัสเท่านั้น

การรับส่งข้อมูล WebSocket อาจผ่านตัวกลางมากกว่าหนึ่งตัว ได้แก่ เบราว์เซอร์, CDN หรือไฟร์วอลล์, ตัวกระจายโหลดภายนอก, ขาเข้า, พร็อกซีโฮสต์ แล้วจึงถึงโค้ด การตั้งค่าหมดเวลาที่นานเกินไปในเลเยอร์หนึ่งไม่สามารถแทนที่การตั้งค่าหมดเวลาที่สั้นกว่าในเลเยอร์ถัดไปได้ ควรเปรียบเทียบเวลาหมดเวลาของการไม่ได้ใช้งานหรือการเชื่อมต่อของแต่ละเลเยอร์ และตั้งค่าขีดจำกัดของเส้นทาง WebSocket ให้ยาวกว่าระยะเวลาการแก้ไขที่ไม่ได้ใช้งานที่คาดไว้ ภายในขอบเขตและนโยบายของแพลตฟอร์มนั้นๆ

อย่าสับสนระหว่างการตั้งค่าการยกเลิกการโหลดเอกสารเมื่อไม่ได้ใช้งานกับการหมดเวลาของเครือข่ายของพร็อกซี การตั้งค่าแรกควบคุมว่ากระบวนการเอกสารที่ไม่ได้ใช้งานจะถูกยกเลิกการโหลดเมื่อใด ไม่ได้ซ่อมแซม WebSocket ที่ตัวกลางปิดไปแล้ว ในทำนองเดียวกัน การตั้งค่าการหมดเวลาที่นานมากก็ไม่ได้แก้ไขเส้นทางการอัปเกรดที่ไม่ดี การรับส่งข้อมูลที่ถูกบล็อก การกำหนดค่า HTTP/HTTPS ที่ไม่ตรงกัน หรือการทำงานผิดพลาดของกระบวนการ CODE หลังจากทำการเปลี่ยนแปลงแต่ละครั้ง ให้ตรวจสอบว่าเวลาปิดเปลี่ยนไปหรือสาเหตุที่บันทึกไว้หายไปแล้ว ซึ่งจะช่วยจำกัดขอบเขตของเลเยอร์ที่รับผิดชอบโดยไม่ทำให้เกิดการเปลี่ยนแปลงที่ไม่เกี่ยวข้อง

ตรวจสอบให้แน่ใจว่าทั้งเบราว์เซอร์ของผู้ใช้และโฮสต์ WOPI สามารถเข้าถึงบริการ CODE ผ่าน HTTPS ได้ และ CODE สามารถเข้าถึงโฮสต์ WOPI ได้เช่นกัน สำหรับการผสานรวม Nextcloud คู่มือการแก้ไขปัญหาแนะนำให้ตรวจสอบปลายทางสาธารณะ/hosting/capabilitiesและ/hosting/discoveryปลายทางจากเบราว์เซอร์curlจากนั้นตรวจสอบปลายทางสถานะ Nextcloud จากเซิร์ฟเวอร์ CODE การตรวจสอบเหล่านั้นยืนยันความสามารถในการเข้าถึงขั้นพื้นฐานเท่านั้น ไม่ได้พิสูจน์ว่า WebSocket ที่สร้างขึ้นจะใช้งานได้นานถึงสิบนาที

ตรวจสอบการซ่อมแซมด้วยการจับเวลา

1. โหลดการตั้งค่าพร็อกซีหรืออินเกรสใหม่โดยใช้ขั้นตอนการตรวจสอบที่รองรับ จากนั้นเปิดเซสชันเอกสารใหม่
2. เปิดเอกสารค้างไว้นานกว่าช่วงเวลาที่เกิดข้อผิดพลาดครั้งก่อน ทดสอบหนึ่งครั้งขณะแก้ไข และหากปัญหาเกิดขึ้นขณะไม่มีการใช้งาน ให้ทดสอบอีกครั้งขณะที่เอกสารอยู่ในสถานะไม่ได้ใช้งาน
3. ตรวจสอบว่า/cool/.../wsการเชื่อมต่อยังคงเปิดอยู่ในการตั้งค่าเครือข่ายของเบราว์เซอร์ และเอกสารยังคงบันทึกผ่านโฮสต์ WOPI ต่อไป
4. ตรวจสอบบันทึกในช่วงเวลาเดียวกัน การทดสอบที่สำเร็จหมายความว่าไม่มีข้อความหมดเวลาของพร็อกซีหรือการปิด WebSocket ที่ไม่คาดคิดปรากฏขึ้น และการแก้ไขจะยังคงอยู่หลังจากเปิดเอกสารอีกครั้ง

หากยังคงตัดการเชื่อมต่อ ให้กู้คืนเวลาที่เกิดข้อผิดพลาดที่บันทึกไว้และเปรียบเทียบกับบันทึกที่แต่ละจุดเชื่อมต่อ การปิดการเชื่อมต่อที่ 600 วินาทีที่จุดรับข้อมูลบ่งชี้ว่าปัญหาอยู่ที่จุดรับข้อมูลนั้น หากเวลาปิดการเชื่อมต่อแตกต่างกันหรือมีข้อผิดพลาดฝั่งเซิร์ฟเวอร์ จะบ่งชี้ว่าปัญหาอยู่ที่จุดอื่น ไม่สามารถระบุสาเหตุที่แท้จริงได้จาก "10 นาที" เพียงอย่างเดียว และชื่อและการตั้งค่าหมดเวลาจะแตกต่างกันไปในแต่ละผลิตภัณฑ์และรุ่นของพร็อกซี โปรดเก็บรักษาการกำหนดค่าที่ใช้งานได้พร้อมเวอร์ชัน CODE และผลิตภัณฑ์พร็อกซีไว้ เพื่อให้สามารถตรวจสอบการอัปเกรดในอนาคตกับตัวอย่างอย่างเป็นทางการในปัจจุบันได้