I wrote a simple script that finds out example peer IPs for a given info_hash. I can't see this kind of information in BEP-0005: how do I actually pull the torrent file from the DHT?
The DHT does not serve torrents. It simply provides peer lists for individual infohashes. Torrent files, or rather the immutable info dictionary, are provided by the bittorrent swarms themselves.
You will have to partially implement BEP3, BEP10 and finally BEP9 to perform the metadata exchange. Additionally implementing BEP29 and BEP11 may provide improved connectivity, which can be useful when retrieving metadata on small swarms
Secondly, consuming resources of the DHT without providing any, or repeatedly hammering nodes with requests - especially the bootstrap node - is considered bad-mannered. If you intend to obtain a large number of torrent files you should run a DHT node as daemon e.g. via Juliusz Chroboczek's dht lib (C) or mine (java). My implementation also contains a metadata retrieval service. libtorrent should also provide all the necessary parts to achieve the same.
Here's a base64-encoded .pcap file that shows the full communication in practice (note the last data packet). Decoding it and opening in Wireshark will show you the full process - combined with BEPs listed in the8472's answer, this could serve as an example.
Cg0NCnQAAABNPCsaAQAAAP//////////AwAbAExpbnV4IDQuNy43LTEwMC5mYzIzLng4Nl82NAAEAC
0ARHVtcGNhcCAxLjEyLjIgKEdpdCBSZXYgVW5rbm93biBmcm9tIHVua25vd24pAAAAAAAAAHQAAAAB
AAAASAAAAHEAAAAAAAQAAgADAGFueQAJAAEABgAAAAwAGwBMaW51eCA0LjcuNy0xMDAuZmMyMy54OD
ZfNjQAAAAAAEgAAAAGAAAAbAAAAAAAAABePwUAEVBWkkwAAABMAAAAAAQAAQAGvF/0eXJ3AAAIAEUI
ADwSdEAAQAYV/QoFtU4FT02hviznAcLkEQgAAAAAoAJyEEblAAACBAW0BAIICgAwA3wAAAAAAQMDB2
wAAAAGAAAAbAAAAAAAAABePwUAS9dWkkwAAABMAAAAAAAAAQAGAAFcmVhFAAAIAEXIADwAAEAANgYx
sQVPTaEKBbVO5wG+LJHhxT3C5BEJoBKpsBhCAAACBAW0BAIICowrE6cAMAN8AQMDB2wAAAAGAAAAZA
AAAAAAAABePwUAftdWkkQAAABEAAAAAAQAAQAGvF/0eXJ3AAAIAEUIADQSdUAAQAYWBAoFtU4FT02h
viznAcLkEQmR4cU+gBAA5e+2AAABAQgKADADn4wrE6dkAAAABgAAAKgAAAAAAAAAXj8FALnXVpKIAA
AAiAAAAAAEAAEABrxf9HlydwAACABFCAB4EnZAAEAGFb8KBbVOBU9Nob4s5wHC5BEJkeHFPoAYAOWS
fwAAAQEICgAwA5+MKxOnE0JpdFRvcnJlbnQgcHJvdG9jb2wAAAAAABAAAS8LTqkWlonb4v9JQHUAwB
V1zWOiLWx0MEQ2MC0S839rfuHUu/yML4eoAAAABgAAAGQAAAAAAAAAXj8FADBgV5JEAAAARAAAAAAA
AAEABgABXJlYRQAACABFyAA01vVAADYGWsMFT02hCgW1TucBviyR4cU+wuQRTYAQAVTu3wAAAQEICo
wrE8sAMAOfZAAAAAYAAAAgAQAAAAAAAF4/BQDwYVeS/wAAAP8AAAAAAAABAAYAAVyZWEUAAAgARcgA
79b2QAA2BloHBU9NoQoFtU7nAb4skeHFPsLkEU2AGAFUnnoAAAEBCAqMKxPLADADnxNCaXRUb3JyZW
50IHByb3RvY29sAAAAAAAQAAEvC06pFpaJ2+L/SUB1AMAVdc1joi1sdDBENjAtinilZ4eOkwl3Zn+F
AAAAbhQAZDE6ZWkwZTE6bWQxMTp1dF9tZXRhZGF0YWkyZTY6dXRfcGV4aTFlZTEzOm1ldGFkYXRhX3
NpemVpMzgzOWUxOnBpNTkxMzdlNDpyZXFxaTIwNDhlMTp2MTc6bGliVG9ycmVudCAwLjEzLjZlAAAA
GQUAIAEAAAYAAABkAAAAAAAAAF4/BQAcYleSRAAAAEQAAAAABAABAAa8X/R5cncAAAgARQgANBJ3QA
BABhYCCgW1TgVPTaG+LOcBwuQRTZHhxfmAEADt7mcAAAEBCAoAMAPDjCsTy2QAAAAGAAAAyAAAAAAA
AABePwUAgGJXkqUAAAClAAAAAAQAAQAGvF/0eXJ3AAAIAEUIAJUSeEAAQAYVoAoFtU4FT02hviznAc
LkEU2R4cX5gBgA7RBfAAABAQgKADADw4wrE8sAAABSFABkMTptZDExOnV0X21ldGFkYXRhaTJlNjp1
dF9wZXhpMWVlMTpwaTQ5MTY0ZTQ6cmVxcWkyMDQ4ZTE6djE3OmxpYlRvcnJlbnQgMC4xMy42ZQAAAA
AAAAADCRrhAAAAyAAAAAYAAAB8AAAAAAAAAF4/BQB54leSXAAAAFwAAAAAAAABAAYAAVyZWEUAAAgA
RcgATNb3QAA2BlqpBU9NoQoFtU7nAb4skeHF+cLkEU2AGAFU7d4AAAEBCAqMKxPsADADw/////////
//////////////////////4HwAAAAGAAAAZAAAAAAAAABePwUARXtYkkQAAABEAAAAAAQAAQAGvF/0
eXJ3AAAIAEUIADQSeUAAQAYWAAoFtU4FT02hviznAcLkEa6R4cYRgBAA7e2FAAABAQgKADAEC4wrE+
xkAAAABgAAAGQAAAAAAAAAXj8FAOaCWJJEAAAARAAAAAAAAAEABgABXJlYRQAACABFyAA01vhAADYG
WsAFT02hCgW1TucBviyR4cYRwuQRroAQAVTtPQAAAQEICowrFBUAMAPDZAAAAAYAAACEAAAAAAAAAF
4/BQAUg1iSYwAAAGMAAAAABAABAAa8X/R5cncAAAgARQgAUxJ6QABABhXgCgW1TgVPTaG+LOcBwuQR
rpHhxhGAGADtUoEAAAEBCAoAMAQMjCsUFQAAABsUAmQ4Om1zZ190eXBlaTBlNTpwaWVjZWkwZWUAhA
AAAAYAAABkAAAAAAAAAF4/BQDZDVmSRAAAAEQAAAAAAAABAAYAAVyZWEUAAAgARcgANNb5QAA2Blq/
BU9NoQoFtU7nAb4skeHGEcLkEc2AEAFU7LEAAAEBCAqMKxQ5ADAEDGQAAAAGAAAAbAAAAAAAAABePw
UA/w1ZkkoAAABKAAAAAAAAAQAGAAFcmVhFAAAIAEXIADrW+kAANgZauAVPTaEKBbVO5wG+LJHhxhHC
5BHNgBgBVMl0AAABAQgKjCsUOQAwBAwAAA8tFAIAAGwAAAAGAAAAZAAAAAAAAABePwUADw5ZkkQAAA
BEAAAAAAQAAQAGvF/0eXJ3AAAIAEUIADQSe0AAQAYV/goFtU4FT02hviznAcLkEc2R4cYXgBAA7ezu
AAABAQgKADAEMIwrFDlkAAAABgAAAAwGAAAAAAAAXj8FAFsRWZLsBQAA7AUAAAAAAAEABgABXJlYRQ
AACABFyAXc1vtAADYGVRUFT02hCgW1TucBviyR4cYXwuQRzYAQAVQfdQAAAQEICowrFDkAMAQMZDg6
bXNnX3R5cGVpMWU1OnBpZWNlaTBlMTA6dG90YWxfc2l6ZWkzODM5ZWVkNjpsZW5ndGhpMTIyMDExND
JlNDpuYW1lMzU6VWJ1bnR1IFRoZSBDb21wbGV0ZSBNYW51YWwgMjAxNi5wZGYxMjpwaWVjZSBsZW5n
dGhpNjU1MzZlNjpwaWVjZXMzNzQwOvq1ayK6Etm4T4hmMT8z0PsZ+HPTtomCPusw+v/ZxRxS35MlyX
XC/uwHO1w0tocuYw3toTL211a5Zz6aJfJfE+Vh2S7XL2UdLB6c5ND6S6t8im5XB7fwW80o0VTem7Vr
dT2P2W7cE8bxZuMKMPNGMfsLKr5nu8f8Aig7o7qOibzwY2LeeM9iohbmYdM+mM4g3n1DMPqYbKUV5y
I6RCHFpRnu8U2JsY4bEmVIPKHQxrjI+Q0tg7gfkEw4SRA1X5SHJbuDpPoudniZbvF9DO7XpEEIYdR8
BNquTogPOT5ooNJPJI/v1INvXmKrGBnmtt/paHpZWU0Gl8JcHHl7BZq0RsG7T5JteHWfNo/sqWqLmr
svZIAsfF2MdTL7r2zp5pUfuIRtQeEjV9Dtja0fTqbx4IhSx3gox+s2OqWOLURMDY+UDEhXn9Ie8fsu
kn+XRI+ihlwOAq8bunAQdgun8apPI7aBS5LAvjrQED/jf42qaKwe4Leq8fSQM4rT1CPnt/hlyp9EYO
L434AGq9a4D+55o+tB6jXTAobqiApOegIWi4aj+dzWXIokLrMcUKC8ZHT+UPFR7woWIEMb0PfGYNVI
Op/nh0t4CMGo1/Jtjd1yJ/AUx2v6d+/IMv+kx2uEDMxZLwSTCdhJ+xgO5uHq3UlATqkgfmBI0RUF3D
ML/eMqBfa6/+nWyfBYyt1/uD0JMLqqSbZQkFpq/VOE5Na7nnHy6T/5Oq1hliB6GmENzWsmUYvy+BS+
+it6J35CkAaZC7Vo7k8Ct5xcxbdpL1gnn2mJsy+PGci9JMVueIwcLDUqI193Vt6xFSxpM5/s0dHDA0
SmCXDOqIvy9Abc3WSBk49ajMvEbV4iZJRdRUSDI/85eqSyL57+s2A1COva+Z3dFlTHfF62pYKGVjS7
+Zysxk009983GKpYedOODTCK4PmEsPEb1BNd1dWIY5Ppt0CI2A4UleJA+cTIZssEct0NsVJlzldsVT
FRbP8JcAteB+KJVXkhDQydfQkhnDwjNJvmpL9Td1V8MC4Jeue3jY47pWjewjHEg62rr4JeTnhFXDG4
GOXPCG7I2/oGyxnRsStPuV2fub1ajweOLKeT3ue9et1qor5VI81w1R5bU3Jke/r43fYRMwzeALVyzC
7UFKe4ivM5s21JwtNsZ874HhQHUZgZHa5yRfIMm/QJqVCde6JR11QeGqeDArw8brqtGLV+v/H75dOX
B1zSmbBhOsF+sEcTt0dQgoVQH50y0UDmWhgtrRoPZgTrYfI+d7DxfMRvgKlJrrv5/NvUtuIW1NA9VS
HpdjgAK4L4B8+H1goUB90SNT30tSOyf+BVL+Cy9XXlIH26X9YvJ3I3yDd36R8NLqWWF+Z095uS/XLV
j1saLWlXD+TBJG02A2jUSnP2Zsu55rc9TXqiE8NpFAY3v0E5Y57XuV02eY8NkJPbb+QWLv4p56Xn7U
0P0FUKt2J33ag/Hn7wvrcjiBtFL5YKzfzMSFM9PlyIz3qEmIa4HF+tGXfDNOc2QVes4fWEuIFr2cDI
vN/eMmbo0xPVQvWypH+4oWpXEefW7hM/v8PmdRW2/IasgYD+cXs1gi4+tU8XZpXsL1x3cKVfeRc8wM
sofjjm4hncjr8EyfJ7vdE6WQuBJsAVCbyt6GowWbQG2AWvVwzGkFlgShu8ZPo1MKAjBOLEUaUZ2Asw
zY27KFxCK7vSUXx6SuyJ7/dlWF2vv94DLlSAydydQjk114lIrvY0wrcMBgAABgAAAGQAAAAAAAAAXj
8FAIcRWZJEAAAARAAAAAAEAAEABrxf9HlydwAACABFCAA0EnxAAEAGFf0KBbVOBU9Nob4s5wHC5BHN
keHLv4AQAQTnLgAAAQEICgAwBDGMKxQ5ZAAAAAYAAAAMBgAAAAAAAF4/BQBnElmS7AUAAOwFAAAAAA
ABAAYAAVyZWEUAAAgARcgF3Nb8QAA2BlUUBU9NoQoFtU7nAb4skeHLv8LkEc2AEAFUH4IAAAEBCAqM
KxQ5ADAEDHLdrT/EhXN8cAOyCumI4uC5vOUsJtRRIo5xOfftqGRhHyrWxlHDd3UfaQMcDYfieGtTKt
w4b0zL/6EA8itJDyvGuYq6lZtpLuGEzhPeKQwgipSuqWS+cRprXUSnzu4BtISU4iUh4Rg5CF9ZdHA8
/O5s5RL0bxA7ep17d6Xyj06PPBXhBNOB21znRzRuzhM3K3ogJvPYUZzmdT/EUAt+esBn1bwRSJlPGj
+LjfdhI52vCHmawcoSNqTa2Whu1uuUCH7jxAvJDw930fobmvqOJCe+vhmjRy9lET/OgD8oh5MxZVYP
KLCLUpqrGV/A0fEfaYW40z8iDCLZUydvFeeWLd1sudAw+zBhPsiFhdleo5YYq9PgHWJmPXxKxKGinH
6XXgwacfE2ZQwZJv5lN5FsNlSQk1b2bsjjR318ocADA6co7OLZMWpilfTnM8hHHRdyEItajHRZ8Tm4
QwuzuACVj70SD8UsUHbPitIm6PIzK5153TN4L6J/iDn21+DKzum8ZlaicEqyDZTo+S0XGFHsQulZ1w
vsg+7LeV4FQTu26MWdFQIE821iMXrbutWEl+9U5/q8vjwhjhmEw8A87U4eYXF5lOld+O+F4LEEoO9+
RRfYnhxGOz70Hmi2kcWBh7qDq8cD2r5mhvqcvZzcGsO5NaTFLHtPDnaFXv5UDpMoZWnYp55BVTW9ox
mqLpxAReRuJVw+EXBqU3UMoEP602uafaPFESv/SbG37jFGfFk3FRkD7Taob7G1iyq4mg179G26BVI9
rKUCyVU22Szaz04Jce4lgypJcK5z8Y/GRNpDXIsD7xyICAii8YgIG5eoXx876iwNebqU1iVOB4sAZc
OjINKBpge6lzh2NKTvFlMJ+OOd3H4nNC8CsJWYfjpmcuMSGIGareGg2RObqKMmZQEkefK/OvJuCgfx
sGKA13sYT06E16h9vGmRFkc6+wMLc/260dUVeYUvyn9oLCtmwmFJLntxCSq0elvIIpIX3zeAy561+D
Hu5aomN3gMAg6oq+3UPXQC5jZMev8b+Q5PY/Qx1vm8eAH41SFx95LAKWUffuxefS3EXDPwAGtudN02
zAcJqpuScJ7G2cie3+aQyc2nAtd57QVayRe+8gzUL5QB8dad20GHT8XU1hgczXqox/AWEYG1ef9rqC
a4oIem6nr0liOivWLDt0dQo+eT928lF5vDMtSfD6HzsVNEcZP0pO6u+ahTBbTcfT7jhCxITq6QERt/
jQFZas7GEIHZK66OnXBeG7IMNLP0o/2WE/JPeZAvOPv61UrP9iaacifZfV8oaZ4niCKp9kQLKMRiQU
FvdDAbUJVlmA71C7WwbgSQiouuNfmHkj1LPmTUPraX7U4WF97O0QzKrLt0GCMd4L30RfA8asn+vPXv
kQ0h0M1RiPrkL90Zuww3S/wXifmh21MMopJ30WF5lu5I5BvPJ3cQ7S8g3N7fFnl63f7xdVK3v3ivh8
O6Jvbjkvtj5JWc/zV+OtTyFT7AoZWO6U0CJ+GXFzrF+8xJdlMTX0S0tLWtNr+aNk/FIVS4EMuz1mha
OW39isF6jQ+VpnQMG5Yd7Ns4Dluoriskk/OkVLOaAZZH1Ha8ozuePg/gSkp4xxagI7KhhYDWGlwfQt
l+DreFQZ//SoKPpKGGCR5wgZw7lb3d6K2ohzMww0dwKCp3qLLfrWbl7N/3metWQVBzdGhak8DJ0dPR
Bttvt+cFGmVhVFYYhbVc9YfIzhLYWoWoN/d0DO1/YI/2IFUeMlHtikODkFVD04fT+RlIiid6hwQwhb
V9Z7AMUT7JE0tyDMKW+iVN6CujHMUlp9EWB3B6OArwuFZBeyDnT+jwkp9Fhj0XiqvqtZWaBJGZeda/
WnzptQmTTf0DRATDfxFeeA9n9nbmyzZpv3BFeQuzP3WokhK3wTANIEM9F7fazn5b17y1DAYAAAYAAA
BkAAAAAAAAAF4/BQCCElmSRAAAAEQAAAAABAABAAa8X/R5cncAAAgARQgANBJ9QABABhX8CgW1TgVP
TaG+LOcBwuQRzZHh0WeAEAEa4XAAAAEBCAoAMAQxjCsUOWQAAAAGAAAAQAQAAAAAAABePwUAf5JZkh
8EAAAfBAAAAAAAAQAGAAFcmVhFAAAIAEXIBA/W/UAANgZW4AVPTaEKBbVO5wG+LJHh0WfC5BHNgBgB
VF6xAAABAQgKjCsUWgAwBDBjx12hMb4dvmVmMbnqdB/1egi6goYQGKvUhTkK8KhYiSARwDczMJ+hIH
xeJd6VeXoeQzrEOFmUPhVTjHwecpRapE77A62xzBRaQwUR4UkUeQA8hIw/BiUFL53pr7l0amBq194C
Yt9zA+P8sT36fzUVliMrPooMj6wr22owrM/b11HrpXHstrJnrmKG0LKgmYHBMNosV8DGlyWKg0OaLW
4D7zNRYGB5Mz/YE8cF+4uUyRAMkx79mUPRQDLiBNz9MnSUIfgijRD/vaL5WesP1NAf0Q+bT8d0qFpN
MmjhoeMlKnOOiZZFc4HG+gK58GrAj+uLiTbxCT6FKZIiOG/FqDU3tFrykGqzLty3eZo9kC0dRwl7OC
kM2tNQ+1tr9RIZz3NfctzVtq1vILNuiKDAzFDsXtZMwhWlzicCYqm+eSqj7BytPfyZCzT5lqmRXr68
ggGDDLqeO/YHXqpFsvR3TFQeNJdPyAAL+kHcSPTRY7+L3W3XbPUfiIJGuJrYUfwCV5+ZvEoHn3P5qt
aEb8LKXuDfzbo7z6KoC8M1ZKQA1AwX5kabF0k+lKPX5HDNLclIJQUr8RyU6k7dU2YQ3DrqdDhNFDcT
67oXb1nZSuQJkzXCzA2Mj2jZflbugup/Yx4L2l1Bw9cCUqsG4bqkAIv0OO7zjENZoALR+a6rilPceN
Sxt/p1S1Urk8NeGGD7fT6ze6PftXbtwwqQCJYrrUT+oigljbNHlcKrjRps5aB7HCWq3+8H/fpmPC5O
XDK95NPIiYm6OzUovfs+K5Q23JBmXZweZsCuSsihg0drj4k/PIFE27d2yAuRDMk80AlDbsXK6pO0Mq
mO8bUzEBbxeTvZwxyo53VwF0GPc+39AnroXf19y20NJLe/dmWcqILYCQ4KLnTOV4i6NGXm8p7/9zBA
YMAgCwtomLw+AmjyeGtZgjbQ3KZhgAsk819jXflehTXgurxg2Ss2JtYrnm+LPUqezZdzpR0G6coEGk
VQOYxgsrH3nO3f6ieXaYl/usOJsXsVcv1DOkUNTvC66worW5PWCFTX5KFhLDNSPfEYMknWsJqKpn8v
6myZDl1GM/wP8vn9z/7YKpYYm0VZpkd1T4Gr0lmt72eCNb2Sc2PZAbwx9Xd6TrOdVzM5LwdBL66HB4
y1Jsi9CRGg/RwBDkHA+UgpKror7f48BOZoI4LINF3Ty64eHXvTdrSP+NoF5JzC6yOhdl91O4ym9KB4
PGCbSX0pjfsxQec5wrdB+Wl/kzBDMb1PhKwVvSC0qMHeAcrg1BFadsNJe7ZAYUtuDsBcu0sxFEyQrJ
on8G+RO+v5HmUAQAQAAAYAAABkAAAAAAAAAF4/BQCqklmSRAAAAEQAAAAABAABAAa8X/R5cncAAAgA
RQgANBJ+QABABhX7CgW1TgVPTaG+LOcBwuQRzZHh1UKAEAEx3TwAAAEBCAoAMARSjCsUWmQAAAAGAA
AAZAAAAAAAAABePwUAd7ZZkkQAAABEAAAAAAQAAQAGvF/0eXJ3AAAIAEUIADQSf0AAQAYV+goFtU4F
T02hviznAcLkEc2R4dVCgBEBMd0yAAABAQgKADAEW4wrFFpkAAAABgAAAGQAAAAAAAAAXj8FAAo6Wp
JEAAAARAAAAAAAAAEABgABXJlYRQAACABFyAA01v5AADYGWroFT02hCgW1TucBviyR4dVCwuQRzoAR
AVTc4wAAAQEICowrFIUAMARbZAAAAAYAAABkAAAAAAAAAF4/BQA7OlqSRAAAAEQAAAAABAABAAa8X/
R5cncAAAgARQgANBKAQABABhX5CgW1TgVPTaG+LOcBwuQRzpHh1UOAEAEx3OQAAAEBCAoAMAR9jCsU
hWQAAAAFAAAAbAAAAAAAAABePwUAe6A2kwEAHABDb3VudGVycyBwcm92aWRlZCBieSBkdW1wY2FwAg
AIAF4/BQCm016RAwAIAF4/BQB4oDaTBAAIAL1BAAAAAAAABQAIABgAAAAAAAAAAAAAAGwAAAA=
Related
What is the preferred way to validate requested DICOM connection against a list of known hosts?
I can connect to the EVT_CONN_OPEN event. But in that, the event.assoc.requestor.info.ae_title element is always empty (b'').
I see from a TCP network analysis, that the name is transmitted. So, where is it?
What is the right way to validate the requesting host?
You could try using EVT_REQUESTED instead, it gets triggered after an association request is received/sent and the AE title information should be available at that point. Unfortunately EVT_CONN_OPEN is triggered on TCP connection which occurs prior to the association request.
If you don't like the host's details you can use the handler to send an association rejection message using event.assoc.acse.send_reject() or abort with event.assoc.abort().
If you're only interested in validating against the AE title you can use the AE.require_calling_aet property to restrict associations to those with matching AE titles.
For the benefit of anyone else looking this up, the correct stage to look this up is in the EVT_REQUESTED event. However you will likely find the details aren't filled in (they are populated AFTER the handler has been called).
So if you want to locate the callers AE in EVT_REQUESTED, you need to locate the A_ASSOCIATE primitive and read them from there. So for example in your handler you can do this to reject remotes:
def handle_request(event):
req_title = event.assoc.requestor.primitive.calling_ae_title.decode('ascii')
if req_title != 'MyAET':
event.assoc.acse.send_reject(0x01, 0x01, 0x03)
return
At least for 1.5.7.
I have a spring-integration flow that starts with a file inbound-channel-adapter activated by a transactional poller (tx is handled by atomikos).
The text in the file is processed and the message goes down through the flow until it gets sent to one of the JMS queues (JMS outbound-channel-adapter).
In the middle, there are some database writes within a nested transaction.
The system is meant to run 24/7.
It happens that the single message flow, progressively slows down and when I investigated, I found that the stage that is responsable for the increasing delay is the read from filesystem.
Below, the first portion fo the integration flow:
<logging-channel-adapter id="logger" level="INFO"/>
<transaction-synchronization-factory id="sync-factory">
<after-commit expression="payload.delete()" channel="after-commit"/>
</transaction-synchronization-factory>
<service-activator input-channel="after-commit" output-channel="nullChannel" ref="tx-after-commit-service"/>
<!-- typeb inbound from filesystem -->
<file:inbound-channel-adapter id="typeb-file-inbound-adapter"
auto-startup="${fs.typeb.enabled:true}"
channel="typeb-inbound"
directory="${fs.typeb.directory.in}"
filename-pattern="${fs.typeb.filter.filenamePattern:*}"
prevent-duplicates="${fs.typeb.preventDuplicates:false}" >
<poller id="poller"
fixed-delay="${fs.typeb.polling.millis:1000}"
max-messages-per-poll="${fs.typeb.polling.numMessages:-1}">
<transactional synchronization-factory="sync-factory"/>
</poller>
</file:inbound-channel-adapter>
<channel id="typeb-inbound">
<interceptors>
<wire-tap channel="logger"/>
</interceptors>
</channel>
I read something about issues related to the prevent-duplicates option that stores a list of seen files, but that is not the case because I turned it off.
I don't think that it may be related to the filter (filename-pattern) because the expression I use in my config (*.RCV) is easy to apply and the input folder does not contain a lot of files (less than 100) at the same time.
Still, there is something that gradually makes the read from filesystem slower and slower over time, from a few millis to over 3 seconds within a few days of up-time.
Any hints?
You should remove, or move files after they have been processed; otherwise the whole directory has to be rescanned.
In newer versions, you can use a WatchServiceDirectoryScanner which is more efficient.
But it's still best practice to clean up old files.
Finally I got the solution.
The issue was related to the specific version of Spring I was using (4.3.4) that is affected by a bug I had not discovered yet.
The problem is something about DefaultConversionService and the use of converterCache (look at this for more details https://jira.spring.io/browse/SPR-14929).
Upgrading to a more recent version has resolved.
I have a transacted Camel route with a number of processors
from(Constant.RouteA)
.transacted()
.process(processor1)
.process(processor2)
.process(processor3)
.wireTap(Constant.RouteB)
.wireTap(Constant.RouteC)
.end()
My problem is that I don't want the final part of the route (the wiretaps) to be part of the transaction i.e. I want them to be executed once processor3 has finished and the transaction committed.
Initially I looked at using onCompletion() but it doesn't seem to work together with transacted().
So I found another way which requires using policy() to limit the transaction scope i.e.
from(Constant.RouteA)
.policy("PROPAGATION_REQUIRED")
.process(processor1)
.process(processor2)
.process(processor3)
.end()
.wireTap(Constant.RouteB)
.wireTap(Constant.RouteC)
.end()
The problem is that this solution requires to define the SpringTransactionPolicy in the Spring configuration, but the software I'm working on doesn't use Spring. Transactions are managed by Bitronix and everything works just by using the transacted() method, which as far as I can tell doesn't allow you to limit the scope of a transaction.
Is there a simple way to achieve my goal? Hopefully without bringing Spring into the picture. Thank you!
Try to create two routes. For example:
from(direct:startRoute)
.to(Constant.RouteA)
.wireTap(Constant.RouteB)
.wireTap(Constant.RouteC);
from(Constant.RouteA)
.transacted()
.process(processor1)
.process(processor2)
.process(processor3);
Once route "Constant.RouteA" is finished all changes will committed.
im using errbit 0-3 stable and its working really good .
but the problem is sometimes it start spamming me emails for the same error but different hashes like the following :
Mongo::Error::NoServerAvailable: No server is available matching preference: #<Mongo::ServerSelector::Primary:0x007fdba42891f0 #tag_sets=[], #options={:database=>"db_test", :max_pool_size=>200, :wait_queue_timeout=>5, :write=>{"w"=>0}}, #server_selection_timeout=30>
Mongo::Error::NoServerAvailable: No server is available matching preference: #<Mongo::ServerSelector::Primary:0x007fdbb8148e30 #tag_sets=[], #options={:database=>"db_test", :max_pool_size=>200, :wait_queue_timeout=>5, :write=>{"w"=>0}}, #server_selection_timeout=30>
How can i filter them so it would group them into 1 error only ?
There's two ways to deal with this.
Option 1) Catch the errors in your application and scrub the uniqueness out of the error messages before sending them to Errbit.
Option 2) Errbit supports configurable "fingerprinting" so you can actually tell Errbit what attributes contribute to the uniqueness of error notifications. This can be done system-wide or on individual Errbit apps. In your case, you could toggle off the error message as part of the Error fingerprint.
From the Errbit README:
The way Errbit arranges notices into error groups is configurable. By
default, Errbit uses the notice's error class, error message, complete
backtrace, component (or controller), action and environment name to
generate a unique fingerprint for every notice. Notices with identical
fingerprints appear in the UI as different occurences of the same
error and notices with differing fingerprints are displayed as
separate errors.
Changing the fingerprinter (under the 'config' menu) applies to all
apps and the change affects only notices that arrive after the change.
If you want to refingerprint old notices, you can run rake
errbit:notice_refingerprint.
1. When using encrypted media extensions on GoogleCast, from the example code here (section 8.4)
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#examples:
what should be specified for PlayReady in:
video.setMediaKeys(new MediaKeys(keySystem));
as a keySystem?
2. In the same function, there is initData var (event.initData) in function handleKeyNeeded(event). If it is extended by adding custom data, will it be preserved by the DRM engine while license request generating and if not, how to workaround it?
In answer to your first question:
video.setMediaKeys(new MediaKeys("com.microsoft.playready"));
However it would be prudent to query the what systems are supported for given media types using iTypeSupported as per:
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-istypesupported