Login

Recent searches

No recent searches

Search options

Not available on mastodon.xyz.
mastodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance, open to everyone, but mainly English and French speaking.

Administered by:

Server stats:

812
active users

mastodon.xyz: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.4

#queue

0 posts0 participants0 posts today
Public
jexner

Phew! I need to figure out a way to get data from a Raspberry Pi into a database on a server over an unreliable network.
The data is not a stream, but there is a new data point being generated every 5 minutes.
I'm thinking I need something like a local queue on the Pi, and once Internet is there, the elements from the queue need to be transferred, one by one, then added into the database.
Rabbit hole, here I come!
#BuildInPublic #Internet #database #queue

Public
Fedify: an ActivityPub server framework

Got an interesting question today about #Fedify's outgoing #queue design!

Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.

In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.

By creating individual queue items for each recipient:

  • Fast servers get messages delivered promptly
  • Slow servers don't delay delivery to others
  • Failed deliveries can be retried independently
  • Your UI remains responsive while deliveries happen in the background

It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.

This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!

What other aspects of Fedify's design would you like to hear about? Let us know!

A flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
#ActivityPub#fedidev
Replied in thread
Public
ミル

@a the way it worked on tumbl was as a reblog with the #queue hashtag... given how quotes/emptyquotes/boosts work on here (or rather barely work) gives me hope that i can just slap an invisible or tiny tag on em
or have ppl know
but yea i guess a booster bot might be a simpleriidea...

Public
Gea-Suan Lin

使用 SQLite 實作出 API 相容 Amazon SQS 的 SmoothMQ

在「Show HN: Drop-in SQS replacement based on SQLite (github.com/poundifdef)」這邊看到的，就如同標題所提到的，是個 Amazon S

blog.gslin.org/archives/2024/0

Gea-Suan Lin's BLOG · 使用 SQLite 實作出 API 相容 Amazon SQS 的 SmoothMQ在「Show HN: Drop-in SQS replacement based on SQLite (github.com/poundifdef)」這邊看到的，就如同標題所提到的，是個 Amazon SQS 的相容 API 實作，專案在 GitHub 上的「SmoothMQ」這邊。 底層是 SQLite，實作語言是用 Go，然後有 web interface 可以觀察與管理。 不過 Amazon SQS 的 API 層有特別優秀嗎...
#API#AWS#Cloud
ExploreLive feeds
About