s*****w
发帖数: 1527 | 1 【 以下文字转载自 Seattle 讨论区 】
发信人: somehow (淡泊明志，宁静致远), 信区: Seattle
标 题: Help: windows debugging question: "new" caused access violation
发信站: BBS 未名空间站 (Sun Dec 12 22:07:02 2010, 美东)
We develop a SW, after install and reboot.
The 1st time it runs the app, there's a "just-in-time" error.
So hook it to the VS 2005, from the stack i can see our app calls "new",
it calls malloc/heap etc.
Now if i reboot the pc, retry all these, everything is ok now.
Our app has that "user access control" thing, if turn o... 阅读全帖 |
|
l*******t
发帖数: 642 | 2 就是用perl运行外部程序,这个外部程序可能会出错,比如assertion failure.这个时候
会有window出现,提示Abort, Retry,Ignore.请问如何用perl可以detect这种情况?包子
酬谢! 请指教! |
|
c****e
发帖数: 1453 | 3 举一个自己碰到的例子，backend storage system, 因为code的问题，small object太
多，GC开销占到了CPU的70%，有很多request drop, timeout,结果frontend更多的
retry,
最后滩了。有时候是一个instance倒下了， 但是load没有变，会加重别的instance的
负担，这是castrophic地。最后大家都一个一个的完蛋，
当然，这不是GC的问题， 而是看怎么用，怎么profile解决问题。但是系统有个极限，
是会发生最后一根稻草的情况。Throttling， auto-sharding这样东西越是到关键的时
候越是添乱。 |
|
s********i
发帖数: 145 | 4 Some Important Theological Questions are Answered if we think of God as a
Computer Programmer.
Q: Does God control everything that happens in my life?
A: He could, if he used the debugger, but it's tedious to step through
all those variables.
Q: Why does God allow evil to happen?
A: God thought he eliminated evil in one of the earlier revs.
Q: Does God know everything?
A: He likes to think so, but he is often amazed to find out what goes
on in the overnite job.
Q: What causes God to interv... 阅读全帖 |
|
|
r***y
发帖数: 4379 | 6 【 以下文字转载自 JobHunting 讨论区 】
发信人: retry (及时行乐,随遇而安), 信区: JobHunting
标 题: Re: 装了Office 2013，被TMD恶心死了
发信站: BBS 未名空间站 (Mon Jan 21 11:35:07 2013, 美东)
同恨m$这种粗枝大叶的升级
换到 windows 7 后多次删错文件, 丫的explorer在右侧选中一个文件, 如果不小心点
了左侧folers中的parent目录, 右侧居然还是蓝色高亮(xp 中是变成灰色). 你以为选
中的是右边个文件, 实际是它的parent目录. delete 如果不仔细看提示信息, tmd 删
错了.
瘟7 这team的tester该拉出去屠jj |
|
z****e
发帖数: 54598 | 7 语言本身的语法就是一糖水
尤其是oo发展这么多年了
现在就是换你去搞一个新语言出来
你也懂得要干嘛干嘛，java等现成的经验在那边
你再笨也懂得抄啊
问题在于
你用的语言本身是否得到了其他人的认同
也就是别人其它公司对你这个语言的支持怎样？
有人说python后面有google，那ruby背后有谁？
ruby背后有sap，但为什么你不看看java背后有谁？
google也好，sap也罢，这都是jcp的成员
还有ibm, oracle, red hat, twitter, intel, hp ...
arm limited甚至高盛
这个名单一长串，其它语言差远了
所以retry说得多好
当你对这个有疑问的时候，看看各大公司都在干嘛
你自然知道怎么选择了
当然如果你不知道ibm，sap这些的话
那我也没有办法
一个好汉三个帮，众人拾柴火焰高
是吧
当然也要谨记一点
不要把鸡蛋放在一个篮子里
所以google也好，m$也罢，这都只是一家公司
但凡是只有一家公司的东西，我都非常谨慎
甚至连spring这样开源的，我都照样很谨慎地使用
因为mysql被干掉又不是没有发生过
以前用mysql，现在... 阅读全帖 |
|
z*******3
发帖数: 13709 | 8 都这种东西了，还要框架，你们也好意思出来说框架
实话说，这种小软件，我一般从底层开始写，顶多用点api
框架就不用了，google搞了一个什么app的inject的guice框架
我看纯粹是吃太饱了撑着，这么简单东西搞那么复杂，何苦何必？
就像swing也可以用spring一样，但是我从来不建议别人这么用
有人这么用过么？杀鸡用牛刀，我说你们什么时候用牛刀什么时候用鸡刀
貌似总是搞错，小东西上框架，大东西大谈偷懒，这都哪跟哪呀
感觉你们总是把握不住战略重心，总是用轰炸机炸小兵，用机枪打航母
哎
javascript不是真正意义上的垮平台，只不过是各个浏览器独立实现而已
没有一个真正意义上的象jvm一样的东西
这种做法很危险，因为不同浏览器的js引擎可能会出一些单独的问题
比如微软的引擎可能出只有微软的引擎会出的问题
你怎么办？而且组合会很多，jvm为了保证不同平台上的执行能够得到同一个效果
那可是下了大力气的，sun当年不息放弃对java的控制
都要劝说ibm, oracle的加入jcp，这叫什么？伟大的妥协
你们不搞政治不明白这个道理
话说二爷不是问过你们，其他语言有没有jcp一样的... 阅读全帖 |
|
|
k****i
发帖数: 1072 | 10 replication factor 3和quorum写，写了两个replicas然后return write failure了怎
么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
什么区别？
所谓
他的 |
|
w**z
发帖数: 8232 | 11 In this case, client has to retry.
点。 |
|
w**z
发帖数: 8232 | 12 that is certainly possible. Almost all high level C* clients do retry when
it fails. |
|
n*****t
发帖数: 22014 | 13 UDP 也不是不能考虑，前端 timeout retry，后端 timeout refresh
不过我估计每个 request 就 2 个 frame，不需要重新建立连接啥的，10M/s pkt 问题
不大，我是说纯 network IO，毕竟才不到 100M 流量 |
|
n**x
发帖数: 606 | 14 还是那句话，我谁的臭脚也不捧，只是看到这里没有一个人愿意写几行代码测一下。
我提供数据，大家参考一下。 所以不要再说谁捧谁的臭脚了啊。
问题：
古德霸的反例但凡计算机出身的都看得懂。说白了就是在multi-threading的环境下的
顺序问题。
模拟场景：
- 我的机器12 core,我就听大家的用12个线程。
- 每个线程处理1M请求,total 12M的请求平均分布在12个线程上。
- 1000趟车，每趟20个区段，每个区段1000张票。
算法采用老魏的算法，锁区段，不锁线路。 （所谓锁区段也就是interlocked加减）
测试结果（都是平均值）
- 成功出票2M
- 无票可出10M （看完再下结论）
- 抢票过程如果失败Re-Try一次,结果又大约10个请求Re-try成功。
- 全部请求走完后，把所有失败的请求在处理一边，还是没有票。(这个很重要)
结论:
- 古德霸的a->b的反例属于re-try可以成功的例子。 如果retry不成功，那么基本就没
有满足条件的票了。
后续：
性能问题我的场景还不够真实，等我测完后在update. |
|
S*A
发帖数: 7142 | 15 我还想补充的是，如果你的网卡的中断处理是分在不同 core 上的，
一般APIC 都是这么处理的，那么你在串行处理的时候同样不能严格
保证先后次序的。通常的 Lock 只是保证不重入，不能保证 retry 的
先后次序。所以串行化有同样的次序不严格保证问题。除非单 core
单网卡。那样你用数据库就会有流量不够大的问题。 |
|
w**z
发帖数: 8232 | 16 我们经常会向fb 要数据，所以一定是后台异步 with retry. 今天下午fb API就出问题
，down了半小时。 |
|
b*******g
发帖数: 603 | 17 我们说的异步都是前台体验，比如你登记帐户，不当场给你validation，过后给你发信
说ssn错了，那才叫异步。
买东西，不当场跟你说买着没，也叫异步。
至于后台async with retry是很正常的做法。很多服务即使down也可以用缺省值，用最
后一次的值。我们用的是Hystrix.
我的意思是说，不到万不得已，前台都是尽量同步的。比如Obamacare, 多页面，多次
提交验证，让用户修改资料，遥远比一次提交资料，发信说填错了好很多。 |
|
b*******g
发帖数: 603 | 18 不需要维护distributed transaction, 订票都成功了以一个transaction发给DB并且写
入的才是成功的。每
过一段时间，用DB的数据sync 分票服务器。DB才是source of truth, 由于网络错误，
硬件错误没有写入DB而丢掉的票会重新出来。
换句话说，分票服务器保证不会错票，重票。DB sync保证不会丢票。
这不是完全公平的，比如网络丢包造成retry，有可能导致后面的人先上去拿到票。但
所有分布式排队都没有严格意义的公平。 |
|
r***y
发帖数: 4379 | 19 【 以下文字转载自 Java 讨论区 】
发信人: retry (及时行乐,随遇而安), 信区: Java
标 题: bad news:Oracle wins, Google loses in copyright ruling on Java APIs
发信站: BBS 未名空间站 (Tue Jun 3 09:15:16 2014, 美东)
Wow, that sucks!!!
Oracle wins, Google loses in copyright ruling on Java APIs
http://www.pcworld.com/article/2153520/oracle-wins-google-loses |
|
i**p
发帖数: 902 | 20 这是一个root了的Android手机.
3 parts of dmesg here, insmod, remove sd card, insert sd card:
--------------------------------------
insmod mysdio.ko (sd card is in, trace is from my printk. no probe trace
though I add prink to my_sdio_probe)
<7>[ 263.716249] (pid:728, cmd:insmod) my_sdio_driver.drv.name:CRYPTRmicro_
sdio
<7>[ 263.716316] (pid:728, cmd:insmod) my_sdio_driver.drv.bus:0x8049be80
<7>[ 263.716373] (pid:728, cmd:insmod) my_sdio_driver.drv.bus->name:sdio
<7>[ 263.716429] (pid:728, cmd:insm... 阅读全帖 |
|
c********l
发帖数: 8138 | 21 Announcing Amazon Kinesis Client Library for Python
Dear Amazon Web Services Customer,
This week we announced the release of two new enhancements to Amazon Kinesis
. The first is the release of the Amazon Kinesis Client Library (KCL) for
Python developers. The KCL handles complex issues such as adapting to
changes in stream volume, load-balancing streaming data, coordinating
distributed services, and processing data with fault-tolerance. Python
developers can use the library to easily stream dat... 阅读全帖 |
|
g*****g
发帖数: 34805 | 22 scale大的话，不同结点同时 GC的概率很低，即使timeout retry 会 hit不同结点，所
以基本不是问题。 |
|
|
